Active Directory user object inheritance checker

I thought I would tidy up a script I use for Office 365 AADConnect deployments and publish it on the TechNet Gallery.

I use this to check user accounts that have inheritance disabled. From the output I check with the customer to see if this is correct and enable inheritance where necessary. This will throw up errors in Azure AD Connect miis console so it's worth doing as a pre-req check for AADConnect deployments.

You can run the script with or without the -ResultSetSize parameter. It's been coded to default to 1000. Simply utilise it if you have an user object count higher than this.

It's pretty simple to use. Enjoy!

Oliver Moazzezi
@OliverMoazzezi

Planning and deploying directory synchronisation for Exchange Online

I've been involved in many directory synchronisation engagements over the past two years and I thought I would put a post out to help people plan their identity strategy when you want to synchronise your on-premises identities and Exchange Online. I felt the need to write this due to the lack of any consolidated information on the topic and other less complete on the matter articles from around the web!

First and foremost, you need an on-premises Exchange Management Server, Microsoft even provide a free key to license it. If you're moving away from on-premises Exchange then this isn't such an issue, but if you're moving to Exchange Online and haven't had Exchange on-premises before this means you need to plan for the deployment of an on-premises Exchange Management Server. Why? You simply won't be able to fully manage your objects in the Exchange Administrative Center in Office 365 with directory synchronisation in place. Instead you add email addresses, or enable external access to distribution lists by making that change on-premises. Directory synchronisation via AADConnect then replicates that change. You can get around it - but you won't be supported!

So when I engage a customer what are the high level actions I check for? Here's my definitive list.

Check if directory synchronisation has been enabled in Office 365
The first is rather easy to check for, you simply check in the Office 365 Admin Centre, if it's already in place then we need to understand if it's actually being used - we can check for synchronised user and group objects, or if it's not in use, understand who's turned it on and where they may have got to. Beware that if you disable directory synchronisation it can take up to 72 hours to disable! I have verified this from disabling the feature in tenants, I have seen anything between 12-60 hours.

Gather data on Active Directory Domain Controller OS Version
So why do we need this? If we plan to utilise features like password synchronisation, and we plan to home the AADConnect agent on a Domain Controller then we need to ensure they are Windows Server 2008 OS or above. Further, it needs to be a writeable Domain Controller, and there's also pre-requisites for features like password write-back. You can see the check list here.

Gather data on Active Directory Domain and Forest functional levels
If we are planning on introducing an Exchange 2016 management server - some bearing on Forest and Domain functional levels will need to be understood.

Password write-back to on-premises only requires DFL/FFL of Windows 2003, but Windows 2008 Domain Controllers with SP2, however if you are planning on having an Exchange 2016 management server with CU3 or later, then you must have DFL/FFL of at least Windows 2008.

This means that you may find you need to upgrade your on-premises Active Directory to get the features you need. This could be as easy as upping your DFL/FFL levels, to having to actually introduce new Domain Controllers to be able to achieve this.

Gather data on Active Directory sites
I gather data on Active Directory sites to help understand the network topology. Where's the best place to house AADConnect? Which location? Where are the most users homed? Does the customer require a staging AADConnect server - if so which location would be the best to home it?

Gather data on Active Directory Unique Principal Name (UPN) utilisation
I see a lot of customers still utilising .local domains, or domains that have no bearing on their actual routable domains in Office 365. The best move forward is to have the on-premises users have the same UPN as the desired sign in for Office 365. So if the user on-premises is oliver.moazzezi@company.local and they have a cloud user account of oliver.moazzezi@company.com, there's a planning excercise here to understand what domains are in Office 365 and what UPN suffixes need to be added to Active Directory. We then plan the change to update on-premises to oliver.moazzezi@company.com

Number of Objects in Active Directory
We gather the number of objects in Active Directory not so much as an excercise for any limits in Azure AD (there's an initial 150k object limit which can be removed for Office 365 subscriptions), but for SQL licensing for AADConnect, if it's over 100,000 objects we need to be looking at using SQL Standard or above - rather than the free version SQL Express version that is auto-installed with AADConnect otherwise.

AD Replication Health
Checking the health of your AD goes without saying - you need a healthy AD without replication issues to ensure all necessary replications occur and are synchronised to Azure AD. Fix and resolve any issues you find! There's no point replicating to Azure AD if your own intersite and/or intrasite replication is broken!

Check for Deployment of Exchange
If the customer is coming from Exchange and migrating to Exchange Online, this isn't so hard to immediately check and ratify. However, what if the customer has come from Notes, Zimbra - or even a hosted exchange platform or resource forest model?

To be in a supported state you need an Exchange Management Server on-premises. Sensibilities dictate this would be an Exchange 2016 or possibly 2013 management server. This will give the customer the best possible experience in a unified UI and Powershell cmdlet experience across both on-premises Exchange and Exchange Online.

One of the things I have encountered countless times is the incorrect removal of Exchange Server from on-premises. One customer had three Exchange 2003 Servers that were simply turned off, removed from the racking and disposed of - and on-premises Exchange was classified as removed. Upon performing discovery, it became clear this needed correct removal - and further investigation showed nearly every long standing employee still logically had a mailbox!

Check Exchange Version
Following on from checking for previous Exchange deployments, it's important to understand the version of Exchange currently on-premises and the steps needed to put an Exchange 2016/2016 Management Server in-place. As well as the previously mentioned similar management experience you also do not have to worry about upgrading the management server anytime soon - where for example if you had an Exchange 2010 management server, this is going to fall out of supportability long before Exchange 2016.

Check for Mailboxes on-premises
Checking for mailboxes on-premises, when all users are known to be in Exchange Online will require clean-up of the on-premises mailboxes prior to implementing directory synchronisation. It can be done afterwards, but it will likely get forgotten about or missed.

Check for Mail Enabled Users
When planning for the Exchange management server, ultimately all your synchronised users will be Mail Enabled users - this is so they show up in the on-premises Exchange Administrative Center and you can easily modify the Exchange attributes - allowing Azure ADConnect to synchronise them to Azure AD and subsequently your EXO tenant.

Check for Mail Enabled Distribution Groups
Are you planning on synchronising your on-premises distribution lists, or will you be utilising Cloud only? Or will you decide to only synchronise certain ones for security management, and implement Office 365 Groups in your Exchange Online deployment?

Most of this comes down to what you understand, or help the customer understand, what they are ultimately trying to achieve. If the customer is already in Exchange Online and you see a completely different set of security and distribution groups on-premises to what's in Office 365 - you may recommend to the client to just synchronise users.

Check Accepted Domains in Office 365
Are all domains verified in Office 365? Is anything unnecessary or incorrect? Ratify the list here as this will have a bearing on what you assign to on-premises.

Check Accepted Domains
When deploying the Exchange management server ensure you understand the Accepted Domains in Office 365 - you'll need to add these in the on-premises deployment so you can easily additional SMTP addresses to objects.

Check if directory synchronisation has been enabled in Office 365
If Directory Synchronisation is already in place, this will allow you to plan clean-up activties or additional actions, or allow you to disable it whilst you made a more solid action plan to perform directory synchronisation for the tenant. Beware it can take up to 72 hours to disable this!

Validate recommended AADConnect server configuration
So what does the customer actually want when synchronising their on-premises identities to Office 365? Does the customer want just object synchronisation? Does the customer want password synchronisation also? You will find most customers will benefit greatly when their on-premises username AND password also accesses their Office 365 resources. A unified password is a must. However understand if your customer has any compliance or regulatory requirements - or just has cold feet about Azure AD holding the password hash for all their user accounts.

If password synchronsation utilising the password hash doesn't work for them - steer them down the route of pass through authentication. This will allow for a unified username and password experience but push the authentication of the user back to their on-premises Domain Controllers. It's a much simpler story to tell and ultimately implement than ADFS.

You can also understand your customers availability requirements, is one AADConnect implementation sufficient or would they also desire a server in 'standby' mode, ready to take over (manually I might add at this stage), if the primary server suffers downtime for an extended period of time or cannot be recovered?

Proxy Server usage
Does the customer force all server traffic through a proxy? If so you need to understand this. Does the proxy for example require authentication? If it does you will have to configure web.config files on the server that will home AADConnect to ensure a succesfull deployment.

IDFix
IDFix is a Microsoft tool that will parse user and group objects and report if they have issues that would require clean-up prior to being able to succesfully synchronise. It will pick up on the aforementioned UPN issue - but it's also good for trailing spaces, or objects with duplicate attributes - for example a UPN or proxy address.

Summary
I hope this goes some way to helping you as a consultant, IT admin or inquisitive Office 365 customer on the steps you should be going through to succesfully deploy directory synchronisation for your on-premises Active Directory and Office 365 tenant.
This should provide you the absolute best and reasoned approach to deploying it, capturing any issues in the planning stages, and providing a nice easy and best practice approach to the deployment.


Have fun!

Oliver Moazzezi – Office Servers and Services MVP Twitter: @Olivermoazzezi

duplicate SID from OS templates during Active Directory creation

I built a new test Forest in my Test Lab, deploying from a template Windows 2003 and 2008 images.

The Forest consisted of a Root and 2 childs, an example:

contoso.com
tailspintoys.contoso.com
forthcoffee.contoso.com

I had read an article on the myth of changing the SID of a machine when deploying or cloning from a template. The article is here

However when I came to build my first child domain, I had major issues during the DCPROMO process. The Active Directory installation wizard informed me that the specified domain already existed.


















Now this was news to me :-) and a quick double take confirmed it indeed did not exist, and then I realised both the root Domain Controller that was already running and this new Child DC were spun from the same template.

I remembered that when you DCPROMO a server the SID for the domain is taken from the first server to be promoted - and there was my issue.

So ensure that you use Newsid (retired now and not supported for Windows 2008 R2 or Windows 7) or ensure you properly sysprep any of your templates in your test or production virtualized environments.

Oliver Moazzezi

MVP - Exchange Server

Exchange and RODC/ROGC support

Exchange does not support RODC or ROGC's. Therefore if you are deploying Exchange in an AD Site that has either of these, you must ensure that _writable_ Domain Controllers and Global Catalogs are in that AD Site.

Do not worry about RODC or ROGC's being in the same AD Site as Exchange, Exchange will simply ignore them.



Oliver Moazzezi

MVP - Exchange Server

Mail enabled Contacts in a Hosted Enviroment and the Offline Address Book.

Contacts in a Hosted Exchange environment can be tricky to implement succesfully, with 1) the way Exchange searches object attributes to create an Offline Address Book and 2) Active Directory not allowing 2 objects to have the same proxy address (which in all fairness is actually a great necessary check in the GUI to have – although this can be bypassed with LDAP manipulation! (ADSI too) – Note: having two objects with an identical proxyaddress will break delivery to that address and is considered attribute corruption of Active Directory).

So how does the Exchange 2003 System Attendant (using oabgen.dll) determine objects to be included for OAB generation? - It looks to see if the object has two attributes: a ‘proxyaddress’ and ‘mail’ attribute. It will further check to ensure the primary (SMTP in uppercase) ‘proxyaddress’ matches the mail attribute address.

So how does an Exchange Hoster get around 2 companies having the same contact of john@doe.com for example?

First let me explain the TargetAddress and ProxyAddress attributes on a mail enabled AD contact.

The TargetAddress is their actual email address, for example : bill@microsoft.com
The ProxyAddress is what RUS (if you use it – HMC disables all but Enterprise RUS (enabled for System Attendant operation)) stamps on the objects email addresses tab. RUS can of course be told to bypass objects by unchecking ‘Automatically update email addresses based on recipient policy’. You will find the primary proxyaddress will be the address of the contact, matching the targetaddress, and depending on RUS and Recipient Policy configuration it could well be stamped with further proxyaddresses.

So, john@doe.com – how can two customers have this contact in an HMC/Hosted Exchange environment?

The short answer is they can, but it cannot show up in the OAL. This is due to the Offline Address Book generation specifying proxyaddress attributes I mentioned earlier, rather than also considering targetaddress attributes.

99% of hosters won’t have this problem – and contacts will be generated with a proxy address (something HMC supports by default). However when you run into this problem it does cause customer grief.

One way of bypassing it is to give a bogus proxyaddress, for instance ‘HostedCompanyName.joe@bloggs.com’, where HostedCompanyName is the name of the Hosted Exchange customer.

This does work, but introduces other issues when a user outside the Org performs a ‘Reply All’. Take a look.

Here’s the properties of the contact from the GAL:

Here’s the contact from the AD, I have pulled the info from ADSIEdit:

You can see the highlighted proxyaddress and targetaddress attributes clearly:

When you send a message outside of the Org, and include the contact, if anyone that is also outside the Org does a 'Reply All', they will only see the incorrect proxyaddress and not the correct SMTP address of the contact, which is the targetaddress:

This of course will result in an NDR

The fix? Remove the proxy attribute altogether, removing the contact from OAB generation, or have the primary proxy address match the target address (standard Exchange2003/2007 behaviour) – but something that will cause mail flow issues when you get a customer with the same contact.


Oliver Moazzezi

MVP - Exchange Server

Exporting email addresses from Active Directory

This seems to be a hot topic all the time in the newsgroups so....

Run this at the cmd prompt on one of your Windows 2000 and above servers.

ldifde -f C:\youremailexport.txt -l proxyaddresses

Replace C:\youremailexport.txt with whatever drive letter and text file name you want.

Here's a great kb explaining ldifde http://support.microsoft.com/kb/237677

Have fun!


Oliver Moazzezi

MVP - Exchange Server

Adding a Windows 2008 Core Server to a Domain

To join a 2008 core server to a domain run the following command:





netdom join W2K8DC04 /domain:home.local /userd:yourusernamehere /passwordd:yourpasswordhere

Note: the account must have the correct priviledges to add a machine to the domain, also passwordd isn't a typo - and because this is the command prompt your password isn't hashed *******so make sure no one is looking over your shoulder ;-)

Update: you can just enter a single * and it will then prompt for a password that is hashed.

Once the server has rebooted you can verify this by running:

netdom verify w2k8dc04













Oliver Moazzezi

MVP - Exchange Server

64bit Domain Controllers

What's the benefit you may ask, well plenty if configured correctly!

Here at Cobweb we've just finished our deployment of 64bit DC's. The project was started as we realised if we kept our existing 32bit Domain Controllers we would actually have to double the number to support both our existing Exchange 2003 infrastructure and the soon to be deployed Exchange 2007 service we are launching. Supporting 40,000 mailboxes (approx: at this time) takes a lot of Directory work and the last thing we wanted to do was rack and deploy another farm of Active Directory servers - especially when Rack Consolidation is proving to be so important now with power restrictions DataCentres are starting to enforce.

Ultimately we were left with only one option, upgrade to 64bit.


The general rule of thumb for 32bit GCs is to have 1 processor core for every 4 Exchange processors cores. Note I mention core - not actual processor. Having a 64bit GC extends this support to 1 core for every 8 Exchange cores - as long as the server has enough RAM to support loading the entire of the directory (NTDS.dit file) into RAM.

Thus upgrading to 64bit Directory servers allowed us to keep the same physical number of servers, without having to worry about rackspace or power considerations - and indeed cooling - and has given us the support for both Exchange 2003 and Exchange 2007 into our infrastructure.


Oliver Moazzezi

MVP - Exchange Server