Azure – use Office365 or Azure AD as master record for Active Directory

I've managed large numbers of workstations without AD. I had power tools (Altiris Deployment Solution), but it still hurt in certain situations:

1. Security auditor comes in and says that our default workstation password policy isn't good enough. In order to change password complexity and expiration, etc., on 5,000 machines, we had to write a (nontrivial) script and schedule that to run on all machines. (Good luck catching the laptops, by the way!)
2. Mapping department printers. Sure, we could use the IP number. That means that if Department A and Department B get into a printer war, the remedy involves staking out the printer and then following the offender back to their workstation to remove the printer from their workstation. (I suppose you could buy print management software instead.) Also, how did that printer end up on their workstation in the first place if they're not supposed to use it, and how will you prevent it from ending up there again?
3. There are registry keys for WSUS, so you technically don't need AD for patch management. However, if you include those registry keys in the image, you need to make sure and delete a couple of keys (SusClientID and PingID) or else they will never get updates ever. Or, to be more specific and accurate, only one of them will get updates.
4. Software installs. You can do these with power tools (LANdesk, Altiris, etc.), but that's extra money.
5. "Poison" printer drivers. I've seen a couple of these. The best remedy was a print queue with an updated driver.
6. Windows 7 printing would have epic tantrums unless we set allowed forest/allowed hosts in point and print restrictions. Perhaps this wouldn't be a big deal if all printers were ip-only, as long as User1 never wants to use User2's local printer. Without AD, our techs had to either use gpedit on the workstation or on the master image.
7. You're assuming cloud Exchange, but I'm also going to add that email migrations and other large infrastructural changes without AD are painful on the client end. I scripted the "remove software from old failed migration/add workstation to AD/migrate user's profile from local to domain/demote user from admin to power user/make changes to firewall" jobs and ran them through Altiris. (The Microsoft consultants were suggesting we hire temps with thumb drives until I showed them my kung-fu.)

Also, there are software vendors who look at you like you have three heads when you tell them you have workgroups rather than domains. Altiris runs in workgroups, but your desktop techs are never allowed to change their passwords, for example. (Okay, okay. They can change their password. But they also have to swing by your cube and type their new password into the server, or tell you what their new password is.)

What I'm getting at is: You can manage lots of workstations without AD, but you may need to buy replacement software, and even with nice software you'll run into painful things.

The recommended steps at the end of this post can help greatly: http://community.office365.com/en-us/f/156/t/176968.aspx I have not tested it yet as we have some other users that will use the old exchange for now, but it seems pretty promising. This can be done either per user or for the whole system.

To Recap:

1. Decomissioning the Exchange Server as per MSFT migration instructions does the trick.

2. Taking the following steps disables autodiscover:

   1. Open an elevated Exchange Management Shell and retrieve the current autodiscover virtual directory:

      Get-AutodiscoverVirtualDirectory | fl Name, Server, InternalUrl, Identity

      Copy the Identity value to the clipboard. Note the internal URL

   2. In the Exchange Management Shell, remove the autodiscover virtual directory:

      Remove-AutodiscoverVirtualDirectory -Identity ''

      You will have to confirm by typing a "A".

   3. Check that the autodiscover virtual directory is gone:

      Get-AutodiscoverVirtualDirectory | fl Name, Server, InternalUrl, Identity

      3. Internal mailbox records in AD and they may cause issues:

   Active Directory Users and Groups > View > Advanced Features

   Look at the properties for each user and on the attribute editor tab clear the homeMDB and homeMTA attributes. These are also cleared once the mailboxes are disabled.