Archive | Office 365 and RSS feed for this section

.local again!

1 Dec

Full credit to Mark Parris for the original write up

Active Directory: .local domain design and Office 365.

Active Directory: .local domain design and Office 365.

Microsoft since the release of Windows 2000 Server have recommended that any Windows Server environment promoted to host an Active Directory forest/domain should be configured with a registered Top Level Domain (TLD), such as .com, .net, .org etc.

Many companies have ignored this advice and taken the approach of, my internet presence is for example so I will therefore call my Active Directory forest markparris.local.

This approach to the .local namespace in Active Directory has caused no real issue, with exception of Apple Mac Integration into the environment (see below).

With the onset of the cloud, premises and off premises computing the .localnamespace now causes a potential issue. The .local namespace issue may be resolved with a simple fix or it could involve a fair amount of remediation work.

In order to use Microsoft Office 365 Cloud Services with an on premise Active Directory synchronised via DirSync to the “Microsoft Cloud” the forests namespace or to be more precise the users UPN (User Principal Name) must be an internet registered TLD.   In most companies this can be easily achieved by setting all cloud users UPN’s to their email address (or another registered namespace) and then this is what the user presents to Microsoft, to be authenticated/validated.

In some companies, the .local UPN namespace may already be in use for something else and a UPN remediation project may need to be completed prior to any Microsoft cloud integration. This could again be a simple resolution or a huge global project.

So to summarise, the recommendation is still not to use the .local namespace in any new Active Directory implementation, if you have utilised the .localnamespace and you have a requirement to implement Office 365, then identify and configure a registered UPN for the affected accounts.

To be fair to Microsoft, they did tell you.

DNS name registration with an Internet registrar

We recommend that you register DNS names for the top-most internal and external DNS namespaces with an Internet registrar. This includes the forest root domain of any Active Directory forests unless such names are sub-domains of DNS names that are registered by your organization name (For example, the forest root domain “” is a sub-domain of an internal “” namespace.) Article ID: 300684 – Last Review: February 16, 2011 – Revision: 25.1.

As I put my thoughts down, it has also become apparent to me that anyone with an Active Directory namespace that uses a TLD namespace that is not registered to them will also have this same issue and will also need to configure new UPN’s.

Apple Issues

Mac OS X: About Multicast DNS

You receive an “unexpected error occurred” error message when you try to access resources on a Windows-based network from your Macintosh computer

.local to Office365 SSO

18 Apr

How to prepare a non-routable domain (such as .local domain) for directory synchronization

APPLIES TO: Office 365 Admin
When you synchronize your on-premises directory with Office 365 you have to have a verified domain in Azure Active Directory. Only the User Principal Names (UPN) that are associated with the on-premises domain are synchronized. However, any UPN that contains an non-routable domain, for example .local (like billa@contoso.local), will be synchronized to an domain (like If you currently use a .local domain for your user accounts in Active Directory it’s recommended that you change them to use a verified domain (like in order to properly sync with your Office 365 domain.

What if I only have a .local on-premises domain?

The most recent tool you can use for synchronizing your Active Directory to Azure Active Directory is named Azure AD Connect. For more information, see Integrating your on-premises identities with Azure Active Directory.

Azure AD Connect synchronizes your users’ UPN and password so that users can sign in with the same credentials they use on-premises. However, Azure AD Connect only synchronizes users to domains that are verified by Office 365. This means that the domain also is verified by Azure Active Directory because Office 365 identities are managed by Azure Active Directory. In other words, the domain has to be a valid Internet domain (for example, .com, .org, .net, .us, etc.). If your internal Active Directory only uses a non-routable domain (for example, .local), this can’t possibly match the verified domain you have on Office 365. You can fix this issue by either changing your primary domain in your on premises Active Directory, or by adding one or more UPN suffixes.

Change your primary domain

Change your primary domain to a domain you have verified in Office 365, for example, Every user that has the domain contoso.local is then updated to For instructions, see How Domain Rename Works. This is a very involved process, however, and an easier solution is to add UPN suffixes, as shown in the following section.

Add UPN suffixes and update your users to them

You can solve the .local problem by registering new UPN suffix or suffixes in Active Directory to match the domain (or domains) you verified in Office 365. After you register the new suffix, you update the user UPNs to replace the .local with the new domain name for example so that a user account looks like

After you have updated the UPNs to use the verified domain, you are ready to synchronize your on-premises Active Directory with Office 365.

Step 1: Add the new UPN suffix

  1. On the server that Active Directory Domain Services (AD DS) runs on, in the Server Manager choose Tools >Active Directory Domains and Trusts.

    Or, if you don’t have Windows Server 2012

    Press Windows key + R to open the Run dialog, and then type in Domain.msc, and then choose OK.

    Choose Active Directory Domains and Trusts.

  2. On the Active Directory Domains and Trusts window, right-click Active Directory Domains and Trusts, and then choose Properties.

    Right-click ActiveDirectory Domains and Trusts and choose Properties

  3. On the UPN Suffixes tab, in the Alternative UPN Suffixes box, type your new UPN suffix or suffixes, and then choose Add > Apply.

    Add an new UPN suffixChoose OK when you’re done adding suffixes.

Step 2: Change the UPN suffix for existing users

  1. On the server that Active Directory Domain Services (AD DS) runs on, in the Server Manager choose Tools >Active Directory Active Directory Users and Computers.

    Or, if you don’t have Windows Server 2012

    Press Windows key + R to open the Run dialog, and then type in Dsa.msc, and then click OK

  2. Select a user, right-click, and then choose Properties.
  3. On the Account tab, in the UPN suffix drop-down list, choose the new UPN suffix, and then choose OK.

    Add new UPN suffix for a user

  4. Complete these steps for every user.

    Alternately you can bulk update the UPN suffixes by using PowerShell.

You can also use Windows PowerShell to change the UPN suffix for all users

If you have a lot of users to update, it is easier to use Windows PowerShell. The following example uses the cmdlets Get-ADUser and Set-ADUser to change all contoso.local suffixes to

See Active Directory Windows PowerShell module to learn more about using Windows PowerShell in Active Directory.

  • Run the following Windows PowerShell commands to update all contoso.local suffixes to
    $LocalUsers = Get-ADUser -Filter {UserPrincipalName -like *contoso.local'} -Properties userPrincipalName -ResultSize $null
    $LocalUsers | foreach {$newUpn = $_.UserPrincipalName.Replace("contoso.local","") $_ | Set-ADUser -UserPrincipalName $newUpn}

Connect to Office365 Powershell

14 Apr

So you may have noticed the incredible new feature that Microsoft have rolled out to your Office 365 tenancy called “clutter”

Pain in the ass.

To disable it and to carry out many of useful admin tasks you can connect to your hosted exchange online using the following instructions – Note Im using Win10 on VMWARE Fusion


Open powershell as administrator

Connect PowerShell to Exchange Online

I always recommend running PowerShell as an administrator. To do that, right click on the PowerShell icon and select Run As Administrator from the context menu.

PowerShell Run As Adminstrator

First we need to set the execution policy.

 C:\> Set-ExecutionPolicy RemoteSigned

Next we need to store our Office 365 credentials in a variable. Type the command below and hit enter.

 C:\> $UserCredential = Get-Credential

A dialog box will appear. Type in your Office 365 credentials and click Ok.

Exchange Online PowerShell Credential Variable

The account you use will need permissions to Exchange Online. By default only Global Administrators in Office 365 have Organization Management rights in Exchange Online.

Now let’s connect. In the command below we put our connection info into a variable. This results in less typing later.

 C:\> $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $UserCredential -Authentication Basic -AllowRedirection

Finally, let’s use that variable to connect to Exchange Online and import all Exchange cmdlets into our session.

 C:\> Import-PSSession $Session

To disable clutter for your whole tenancy run the following command;

Get-Mailbox -ResultSize Unlimited | Set-Clutter -Enable $false

Until next time


Excel 2016 freezes on Win 10 – FIX

9 Mar

[FIX] Microsoft Excel 2016 Has Stopped Working On Windows 10

Keep Website with Office 365

19 Sep

Keep your current website when you add your domain to Office 365

To add a custom domain, like, to Office 365, you follow the steps in the domains setup wizard.

If you already have a website outside of Office 365 that uses the domain you’re adding, like, select No, I have an existing website or prefer to manage my own DNS records. Then the wizard will guide you to set up your domain with your domain’s DNS records hosted at your current DNS host. If you don’t have a website, you can opt to have Office 365 set up and manage DNS for your domain instead.

Want to have Office 365 manage DNS for your domain anyway (not recommended)? You must redirect to your current website

This is not the recommended option if you already have a website outside Office 365 that uses your domain (unless you’ve set up an outside website using one of Office 365’s web hosting partners). We recommend that you continue to manage your domain’s DNS at your current DNS host to help prevent problems with access to your current website when you set up your domain with Office 365.

If you still want Office 365 to manage DNS for your domain, you may be able to set up redirection from Office 365 to your current website. If you don’t set up redirection using a static address for your website, people won’t be able to get to your website after you add your domain to Office 365 and change your domain’s nameservers to point to Office 365 nameservers.

Why is access to your website affected? Because nameserver settings tell web browsers, and other Internet services, where to look for your domain. After you change your domain’s nameservers to Office 365, so Office 365 can manage DNS for your domain, web browsers will look for your website at Office 365. Since your website is hosted by a different service, the site won’t be found.

Add your domain to Office 365 and set up redirection to your website

  1. Before you begin, you will need a static IP address or FQDN for your current website. Contact your website hosting provider to get the IP address or FQDN. (Using a dynamic IP address, such as the address returned when you run a program like Ping, will not let you set up reliable redirection because the IP address can change at any time.)
  2. Add your domain to Office 365, following the steps in the domains setup wizard.

    In the wizard, choose the option that you do not have a website with your domain. Do not change your domain’s nameserver records in the setup wizard until you complete the following step.

  3. Follow these steps to create an A record to redirect traffic to your website, using the static IP address (or FQDN) that you got from your current website hosting provider.
  4. We recommend that you also create a CNAME record to help make sure that your customers will find your website whether or not they include www together with your domain name. Follow these steps to add the CNAME record in Office 365 in Office 365.

    If the option to create an A record or CNAME record is not available, see Can’t update the A record or CNAME record?.

  5. Complete the final step of the domains setup wizard, to change your nameserver records to point to the Office 365 nameservers.

Top of Page

Now that you’ve got email accounts and website redirection set up, you can update your domain nameserver (NS) records for the domain to point to Office 365. By setting up email addresses and the A record first, as described above, you and other people in your organization will have email accounts that use the domain address, and your website will still be available at your current website hosting provider after you change the NS records.

NOTE    When you change your domain’s NS records as described here, you change the destination of domain services, such as email, to point to Office 365. Remember—if you’re already using the domain for email outside Office 365, make sure that you’ve created Office 365 email addresses with the domain for your users ( so that they won’t lose email messages when you update the NS records to point to Office 365.

Complete the setup wizard: Change your nameserver records

  1. Sign in to Office 365 with your work or school account.
  2. Go to the Manage domains page.
  3. On the Manage Domains page, for the domain that you’re setting up, choose Complete setup.
  4. Follow the steps to update your nameserver records to point to the Office 365 nameservers.

After you’ve updated your NS records, email will begin to be routed to Office 365, but traffic to the website address that uses the domain will continue to go to your current hosting provider.

Lync Manual Settings

27 Apr

1.In the upper-right area of Lync 2010, click the Gear icon to open the Options page.
2.In the Lync – Options dialog box, click Personal.
3.Next to the sign-in address, click Advanced.
4.Make sure that Manual Configuration is selected and that the configuration values are exactly as follows:
◦Internal server name or IP address:
◦External server name or IP address: