Cannot Verify A DNS Domain In Azure Because You Used .LOCAL or .INTERNAL

A lot of companies have used a non-public domain name for their Active Directory. This meant that they didn’t have to buy an public domain name (but they probably did eventually for email), they had company politics issues, or they wanted to separate public from private (making resolution of external services easier). But this causes a problem when you are trying to federate or sync with Azure Active Directory, and I’ll explain a way to solve that issue here.

The Issue

When we connect a legacy Windows Server AD (LAD) to AAD we need to have both domain names matching. So if the company has an AD called joeelway.internal then they cannot sync or federate that domain to an Azure AD called (the public DNS domain for the company) or (a default domain name for an Azure subscription). This is because is we have a user, Barbara, then her UPNs would mismatch:

  • barbara@joeelway.internal VS OR
  • barbara@joeelway.internal VS


Method one is extreme and disruptive:

  • Rename the domain and deal with any consequences (eek!)
  • Configure internal DNS to resolve names of company-owned external services
  • Re-educate people about their UPNs if they’ve been using UPN to log in

I think we can agree that method 1 is too disruptive. There is a softer approach that you can use:

  • Configure an additional DNS suffix for your domain
  • Change the UPN of users to use the new DNS suffix
  • Re-educate people about their UPNs if they’ve been using UPN to log in

Adding a suffix is easy:

  1. Launch AD Domains and Trusts
  2. Right-click on Active Directory Domains And Trusts (not the domain name) and select Properties
  3. Enter the desired domain name in Alternative UPS Suffixes and click Add


Next you’ll change the UPN of the users. You can do this in AD Users and Computers (very slowly) or Google some PowerShell to do it near instantly at scale.

image #

Users will now have a single UPN for LAD (Azure, Office 365, etc), AAD, (hopefully) their email, and any third party SaaS if you federate your AAD.

A Demo Lab

I bought for my demo lab so I can show the real world solution in classes. If you’re just experimenting, learning, or doing a quick demo, then you can use the Azure default domain name. The default domain name is based on the name of your Azure subscription, for example Use this domain name as the additional suffix in your LAD, and set the UPNs to use this, e.g.; use this UPN for logging into cloud services.

Technorati Tags: ,,

My Early Experiences with Azure AD Connect

I deployed the generally available release of AADConnect to synchronise our Active Directory with Azure AD (Office 365) 24 hours after it was made available. Here’s my early experience.

The download link for Azure AD Connect is quite hard to find! You can download AADConnect from here. The getting started guide/instructions are here.

What is Azure AD Connect?

AADConnect is the new unified way for setting up a connection between your on-premises (“legacy”) Active Directory with Azure AD. The tool is extremely easy to use. For most SMEs, you will:

  1. Create your domain in Azure AD and validate it (operation with your DNS registrar)
  2. Set up an in-cloud service account for Azure AD with global admin rights on the directory
  3. Create a service account in your on-premises AD with Enterprise Admin rights
  4. Install AAD Connect
  5. Run the Express Settings configuration, enter your domain details, and supply the required credentials when prompted

It’s not far from Next > Next > Next. That’s what I did at work to get a directory synchronization using AD Sync.

You can do a customized installation allowing you to:

  • Tweak the configuration
  • Deploy and configure ADFS


How I Set It Up At Work

The configuration is actually pretty simple. We have 2 AD sites in our single domain:

  • On-premises
  • In Azure

All the usual AD engineering was done with AD sites, including site links, etc.

The DCs in Azure are Basic machines in an availability set (keeping them in different fault/maintenance domains or zones in Azure). The first one is a Basic A1, which is more than enough for a normal DC. The second machine is where I have installed AAConnect; I have found this needs a bit more RAM so this machine is a Basic A2 (enough for our small company). This in-Azure DC is the one that synchronises with Azure AD.


My Experience

I actually set up AADConnect while it was still in preview (2nd release). I didn’t do the express installation – which was a mistake because I wasn’t really sure what I was doing! We had previously been using O365 in a limited way with accounts that were created in the cloud; these accounts were failing to synchronize.

I upgraded AADConnect from preview to GA and the issue persisted – the upgrade ran perfectly, though and I blame me for the sync issue. I then decided to uninstall AADConnect so I could completely reconfigure the synchronization. The uninstall worked perfectly (which did not happen with the first preview release) and I reinstalled and reconfigured it with the express installation. A few minutes later, every account, except one, was showing as “Synced with Active Directory”.


The one remaining one was one of the original in-cloud users. That has a sync-generic-failure warning in Synchronization Service Manager (the AAD Sync GUI (C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe) which betrays some of it’s heritage. The stack trace shows an error of “The object located by DN is a phantom”. A metaverse search doesn’t find the user account … so AADSync doesn’t find the user in on-prem AD, but the user is in AAD. However, I can see the user in on-prem AD. Quite odd!

Anyway, other than that 1 user account, I think AADConnect is superb. It’s a huge step forward from DirSync, which is complex to set up, and I found it to be a house of cards. This product looks much better so far, offering an easy setup for most customers, and easy to access and detailed logs.


That one account eventually did sort itself out over the weekend. I have no idea how – it just synchronised and I cannot complain about that! Password write-back is working fine too.

Technorati Tags: ,

Creating & Verifying Your DNS Domain in Azure AD

This post explains how to configure the DNS requirements to configure single sign-on (ADFS) or shared sign-on (synchronisation) in Azure AD (AAD) – you need to create a domain name in Azure AD and prove ownership of the domain to Microsoft.

Why Do You Need Matching Domain Names?

Imagine you have a “legacy” AD (LAD) running on one or more domain controllers called If you have a user called Mary then her user name might be joeelway\Mary. On the Internet, we’re more likely to use a UPN (user principal name), and in Mary’s case that would be

Let’s say that we create an Azure subscription called joeelwayazure. Any user that we create in there will be given a UPN with a suffix of For example, Mary would have This would be both confusing for Mary and for Azure because it doesn’t know that the two UPNs are actually for the same user.

If we want to configure single sign-on using Azure AD, use RemoteApp, or whatever, then we need to make sure that the UPN of the on-premise user account will match that of the in-cloud user account. And we can only accomplish this by creating a domain in AAD that matches the domain name of the LAD. So if my LAD domain name is then I need to make a domain in AAD called

Create The Domain

Do the following:

1) Sign into the Azure management portal

2) Browse to Active Directory > Default Directory > Domains

3) Click Add A Custom Domain

4) Enter the name of the domain name. Check the “I plan to configure this domain …” box if you plan to use ADFS for single sign-on.

5) Click Add and then proceed to the next screen.


5) Note the verification details.


Verify (Prove Ownership Of) Your Domain

You can only use a domain in AAD if you own it. This prevents any Joe from using for the UPNs. You will need to sign into your domain registrar where you manage the DNS domain name (e.g. In my case, that’s a company called Blacknight.

I logged in, browsed to the domain, and created a new TXT record using the details from the still-open verification screen in the management portal.


Now I can return to the Azure management portal, and click Verify. It can take a little time for the record (thanks to the fun of DNS) to be available so you can close the dialog in the management portal. The domain remains in an “Unverified” and unusable state. You can return to the domain, select it, and click Verify at a later time.

Tip: if you are in a lab scenario, you might have old TXT verification records that could prevent verification – make sure you delete these first.


With this done, you now have a verified domain ready for single or shared sign-on. Users can be created in your AAD default directory with a UPN suffix that matches your LAD domain name.

Question: what if your on-permises domain name is something like joeelway.local or joeelway.internal? You can’t host those domains on the Internet so you cannot verify them. I’ll deal with this in a later post.

Technorati Tags: ,,

Microsoft News – 29 June 2015

As you might expect, there’s lots of Azure news. Surprisingly, there is still not much substantial content on Windows 10.


Windows Server

Windows Client



Office 365



Azure’s Biggest “Secret” – Azure Active Directory

Do you know how powerful Azure Active Directory (AAD) is? Do you know it’s not just an Azure or an Office 365 thing? I find that when I talk to people about Azure or when someone else is talking about it, topics like Azure Site Recovery (ASR), VMs in the cloud, or Azure Backup are in the conversation. But very few people talk about AAD, what I think is Microsoft’s killer hybrid service.



Connecting Azure AD

I heard a phrase around Ignite 2015 that I hadn’t before: Legacy AD (LAD); apparently that’s what Microsoft now call the AD that you have been running on servers since Windows Server 2000 (W2000). This is because Microsoft is investing in Azure AD, and expecting you to connect your LAD to AAD. This will make, at the lowest level, your users and their passwords available in the cloud:

  • Federation: Using ADFS, you can connect AAD with LAD. AAD doesn’t store user accounts in this design. Instead details are continued to be stored in LAD, and AAD reaches out to LAD to authenticate or authorise users whenever there is a request – no connection = no sign-in. This is a single sign-on solution.
  • Synchronisation: This is a solution that Microsoft has had many tools for, but now Azure AD Connect (AADConnect) does. Usernames and passwords are synchronised beween LAD and AAD, stored in both locations. The solution is more tolerant of failure than federation but not as scalable. This is known as shared sign-on.

Note that I’ve talked about users so far. We can now register devices in AAD (e.g. Windows 10) and via write-back, send these details back to LAD.

You Might Have Already Connected

You might not know this, but AAD is what provides user services for Office 365 (and other MSFT SaaS products). If you’ve deployed Office 365 with DirSync (or another sync tool) or ADFS then you have already accomplished the above. With a few mouse clicks in the O365 admin portal, you can make your domain appear an the Azure management portal.

AAD – Single Security Database for Microsoft SaaS

Microsoft uses AAD for all of their business cloud services:

  • Office 365
  • Azure
  • Intune
  • CRM
  • Azure Rights Management Services
  • And more

This makes it really easy for a business to enable a user to avail of new services once you have configured AAD: you configure the domain, and then you can bring O365 or any of the other Microsoft online business services to those users in seconds.

Single Sign-On With Third-Party SaaS

Microsoft isn’t stupid; they know that you use third-party cloud services, such as SalesForce. And you know what? Microsoft wants to make that easier for you by enabling single sign-on. So not only can users use their single username/password combination to sign into their PC and access their servers, but now the same credentials can work with Microsoft cloud services and third-party services. This brings “shadow IT” under the control of IT. You can use the free Cloud App Discovery to scan a network, find what online services are being used by the business, and reign these services under control using AAD.

There is an upsell here. Microsoft sells AAD Premium (included in the EMS Suite) to enable SSO with more than 10 cloud services. This upgrade also brings in things like self-service password reset.

The Future is Now

Because AAS is a cloud service, it can be developed and improved at cloud pace which is weeks, not years. Feedback and innovation are driving rapid change. You can register devices, including Windows 10 PCs, with AAD. That’s pretty cool:

  • Mobile workers can register with AAD
  • It makes BYOD and remote working easier
  • Cloud-centric SME’s might not need an on-premises DC anymore

Replacing GPO

If LAD is how we control policy on user devices, and we’re replacing LAD with AAD, how do we configure machines? The answer is Microsoft Intune. Intune can configure policy on managed devices. We’re told (I haven’t verified this for myself yet) that:

  • A customer have configured AAD
  • The customer has licensed for Intune with that domain
  • A user registers their device in the AAD domain
  • That device is automatically enrolled for management by Intune – and getting policy from Intune

How I’ve Done It

At work, we deployed the following solution to get AAD configured:

  • We have 2 on-premises DCs, required for our Hyper-V cluster
  • There is an Azure subscription and an O365 E3 subscription
  • We deployed 2 Basic A-series VMs in an availability set in Azure on a VNET
  • There is a site-to-site VPN connection between the on-prem network and the VNET
  • The Azure VMs are joined to the domain and promoted to be DCs
  • AADConnect is installed on one of the in-Azure VMs to connect with AAD (O365)
  • Configure the domain in Azure AD via the O365 Admin Portal

And from there, we’ve opened up all of the power of Azure AD … albeit requiring additional licensing for the Premium edition Smile

Technorati Tags: ,

Azure AD Connect is Generally Available

Thenews that AADConnect is now GA is great for anyone battling with synchronizing to Azure Active Directory (Azure AD or AAD). This tool really is going to be the start of connecting your business to Microsoft’s cloud solutions:

  • Azure
  • Office 365
  • Intune
  • RMS
  • CRM
  • And many more, including third-party solutions via AAD single sign-on

Why? Because you need to get users into the common AAD before these services become meaningful. I’ve used AAD in two different preview releases and found it really simple to get going. Any work that I’ve done with Azure RemoteApp has be done with this tool. Why didn’t I use DirSync? Because I found it to be unreliable. AADConnect solves a big problem too – which AD sync tool should I use – now you use just one tool.

According to Microsoft:

With a rich set of sync and write-back capabilities, you can:

  • Enable your users to perform self-service password reset in the cloud with write-back to on premises AD
  • Enable provisioning from the cloud with user write back to on premises AD
  • Enable write back of “Groups in Office 365” to on premises distribution groups in a forest with Exchange
  • Enable device write back so that your on-premises access control policies enforced by ADFS can recognize devices that registered with Azure AD. This includes the recently announced support for Azure AD Join in Windows 10.
  • Sync custom directory attributes to your Azure Active Directory tenant and consume it from your cloud applications

You can also use AADConnect to connect different AD forests.

In related news Azure AD Connect Health was also released to help customers troubleshoot what’s going on with ADFS. This new feature is included in Azure AD Premium.

This release for ADFS has 3 key capabilities:

  • Alerts based on events, configuration information, synthetic transactions and perf data. So, when something goes wrong, or is about to go wrong, we let you know.
  • Graphs of login activity that you can pivot multiple ways for easy viewing. These “usage insights,” are accessible when you enable auditing on your ADFS servers. They are based on audits generated when user’s login and tokens are generated for applications.
  • Access to key performance indicators across multiple servers, including token request counters, processor, memory, latency, and so forth

Microsoft News 02-June-2015

The big news of the last 24 hours is that Windows 10 will be released on July 29th. I posted before The Verge, etc, that I will be away and not reporting on the release on that date.


Windows Server

Windows Client




Microsoft News – 25-May-2015

It’s taken me nearly all day to fast-read through this lot. Here’s a dump of info from Build, Ignite, and since Ignite. Have a nice weekend!


Windows Server

Windows Client

System Center


Office 365


  • Announcing support for Windows 10 management with Microsoft Intune: Microsoft announced that Intune now supports the management of Windows 10. All existing Intune features for managing Windows 8.1 and Windows Phone 8.1 will work for Windows 10.
  • Announcing the Mobile Device Management Design Considerations Guide: If you’re an IT Architect or IT Professional and you need to design a mobile device management (MDM) solution for your organization, there are many questions that you have to answer prior to recommending the best solution for the problem that you are trying to solve. Microsoft has many new options available to manage mobile devices that can match your business and technical requirements.
  • Mobile Application Distribution Capabilities in Microsoft Intune: Microsoft Intune allows you to upload and deploy mobile applications to iOS, Android, Windows, and Windows Phone devices. In this post, Microsoft will show you how to publish iOS apps, select the users who can download them, and also show you how people in your organization can download these apps on their iOS devices.
  • Microsoft Intune App Wrapping Tool for Android: Use the Microsoft Intune App Wrapping Tool for Android to modify the behavior of your existing line-of-business (LOB) Android apps. You will then be able to manage certain app features using Intune without requiring code changes to the original application.



Ignite 2015–Windows 10 Management Scenarios For Every Budget

Speakers: Mark Minasi

“Windows 10 that ships in July will not be complete”. There will be a later release in October/November that will be more complete.

Option One

Windows 7 is supported until 2020. Windows 8 is supported until 2023. Mark jokes that NASA might have evidence of life on other planets before we deploy Windows 10. We don’t have to rush from Windows 7 to 10, because there is a free upgrade for 1 year after the release. Those with SA don’t have any rush.

Option Two

Use Windows 10. All your current management solutions will work just fine on enterprise and pro editions.

Identity in Windows 10

Option 1: Local accounts, e.g. hotmail etc.

Offers ID used by computer and many online locations. Let’s you sync settings between machines via MSFT.  Let’s store apps roam with your account. Minimal MDM. Works on Windows 8+ devices. It’s free – but management cost is high. Fine for homes and small organisations.

Option 2: AD joined.

GPO rich management. App roaming via GPO. Roaming profiles and folder redirection. Wide s/w library. Must have AD infrastructure and CALs. Little-no value for phones/tablets. Can only join one domain.

Option 3: Cloud join.

Includes Azure AD, Office 365, Windows 10 devices. Enable device join in AAD, create AAD accounts.  Enables conditional access for files. DMD via Intune. ID for Store apps. Requires AAD or O365. On-prem AD required. Can only join one AAD. Can’t be joined to legacy AD. No trust mechanisms between domains.

The reasons to join to the cloud right now are few. The list will get much longer. This might be the future.

Demo: Azure AD device registration.

Deploying Apps to Devices

Option 1: Use the Windows Store

Need a MSFT account and credit card. You can get any app from the store onto Windows 8+ device. Apps can roam with your account. LOB apps can be put in the store but everyone sees them. You can sideload apps that you don’t want in the store but it requires licensing and management systems. Limited governance and requiring everyone to deploy via credit card is a nightmare.

Option 2: Business Store Portal

New. Web based – no cost. Needs AAD or MSFT account. Lot into MSFT account and get personal apps. Log in with AAD account and get organisational apps. Admins can block categories of apps. Can create a category for the organisation. Can acquire X copies of a particular app for the organisation.

Option 3: System Center Configuration Manager

System Center licensing. On-premises AD required. Total control over corporate machines. Limited management over mobile devices. You can get apps from the Business Store in offline mode and deploy them via SCCM. When you leave the company or cannot sign into AD/AAD then you lose access to the org apps.

Controlling Apps in Windows 10

Session hosts in Azure:

You can deploy apps using this. RDS in the cloud, where MSFT manages load balancing and the SSL gateway, and users get published applications.

Windows 10 has some kind of Remote Desktop Caching which boosts the performance of Remote Desktop. One attendee, when asked, said it felt 3 times faster than Windows 8.x.

Device Guard:

A way to control which apps are able to run. Don’t think of it as a permanent road block. It’s more of a slowdown mechanism. You can allow some selected apps, apps with signed code, or code signed by some party. Apparently there’s a MSFT tool for easy program signing.

Hyper-V uses Virtual Secure Mode where it hosts a mini-Windows where the LSA runs in 1 GB RAM. < I think this will only be in the Enterprise edition > This is using TPM on the machine and uses virtual TPM in the VM. Doesn’t work in current builds yet.

Guest on RunAs Radio Talking Azure RemoteApp

Richard Campbell, the host of the RunAs Radio podcast, saw a tweet from me talking about Azure AD, and thought he should ask me back on to have a chat. I had been working on developing training materials on RemoteApp. The use-case that caught my interest was the ability to use RemoteApp to remove the effect of latency. We talk for half an hour about this.


The “design” I talk about in the podcast (recorded a few weeks ago) works, and I’ve presented using it. I’ve written some posts on about my experiences:

In the design, virtual DCs, file server, and application servers run as VMs in an Azure network. RemoteApp publishes applications on another network. A VNET to VNET VPN connects the server and RA networks, enabling the RA session hosts to join the domain. Users log into RemoteApp, and then it’s all normal RDS at that point:

  • GPO applies
  • Log in script runs
  • Published applications have fast access to application servers
  • Users save data in the company’s Azure VMs

It’s a nice solution!