Overview
NOTE: I wrote this in early 2014 however I did not publish it until now.
So we are taking the leap into Cloud with Office 365. My focus has been on the EFSS (Enterprise File Synchronization and Sharing) space. In this case OneDrive for Business (ODFB) which is part of SharePoint Online in the Office 365 suite. This posting is the beginning of what I am calling the normalization of UPN. The UPN is one way to authenticate for Microsoft resources such as logging into a workstation or the Office 365 service in this post. The other being the traditional down-level method. As others in my firm look to Exchange Online and Skype for Business Online, I will have done a huge part of the prep work for their endeavors.
So we are taking the leap into Cloud with Office 365. My focus has been on the EFSS (Enterprise File Synchronization and Sharing) space. In this case OneDrive for Business (ODFB) which is part of SharePoint Online in the Office 365 suite. This posting is the beginning of what I am calling the normalization of UPN. The UPN is one way to authenticate for Microsoft resources such as logging into a workstation or the Office 365 service in this post. The other being the traditional down-level method. As others in my firm look to Exchange Online and Skype for Business Online, I will have done a huge part of the prep work for their endeavors.
Issue
So whats the issue? In my AD investigation I found over 14 different syntaxes for the UPN. Some examples being:
Most of this is due to automated migration tools such as ADMT. Simply put, our users would be SO confused on what to use to access Office365 resources like ODFB. So we had to fix this and normalize everyone to follow the same syntax. The easiest was to do samAccount@ForestRootDomain however this ran into conflict with our SIP plans.
Per MS documentation, they suggest the UPN match the primary SMTP address attribute. Being an international firm we do business not only as @mycompany.com but also as @mycompany.countrycode in certain countries so the primary SMTP address doesn't necessarily match the Forest Domain. While we could add all these other domains (around 100 SMTP domains for us) via ADDT, I chose to keep the UPN matched to the Forest root Domain syntax after internal conversations.
So with that said, I chose to break this project into phases with the first phase to fix the domain suffix, while the second is to normalize the prefix and subsequent phases to look at things like the SIP address. This post covers Phase I.
So with that said, I chose to break this project into phases with the first phase to fix the domain suffix, while the second is to normalize the prefix and subsequent phases to look at things like the SIP address. This post covers Phase I.
Resolution
There are several scripts out there that act as a broad sword to forcibly change every user objects UPN, but with our size and AD organization I needed a steady handed brain surgeon as we have non named user objects such as service accounts that should not be changed and are really outside the scope of this project. Nor do they need to take an Office365 license. Therefore we had to target specific user objects for this change.
Step One
I took ADFind and exported all the users relevant fields. adfind -csv -t 500 -h LOCALDC.my.domain.com -b "dc=my,dc=domain,dc=com" -f "&((objectcategory=person)(objectclass=user))" -nodn samaccountname userPrincipalName employeeID sn givenname name >> prod_List.CSV
In the ADUC GUI, UPN is broken into the prefix and suffix however it technically is one attribute so the easiest way to deal with that is to break the UPN into two separate columns for quick sorting. I used PSPAD, but any text editor like notepad, works fine as well as scripting it. Open the .CSV and do a search for
@
and replace with
","
Note you will need the quotes as ADFind escapes each column with quote and it can mess up the next step. Additionally if you have objects that legitimately has the @ sign in the UPN those objects will look all quirky and need more manual work.
Step Two
Import the CSV file into your favorite spreadsheet program like Excel and sort by column C (domain suffix). Then delete the correct record rows leaving only the ones needing to be changed. Save this out as an XLSX file.Step Three
I had Cory Becht do his magic yet again and throw together a script much more eloquent them my attempt. It will look at the XLSX file and parse the samaccount from the first column and change the UPN domain suffix to what you set in the script. The other columns are just for sorting and verification. You will need to modify lines 29, 35, and 38 in Cory's script for your environment.
Download
This script is provided as-is, no warranty is provided or implied.The author is NOT responsible for any damages or data loss that may occur through the use of this script. Always test, test, test before rolling anything into a production environment.You can find my ADFind script and Cory's script to change them here. You just need to grab ADFind from Joeware and put in the same dir as these two.
No comments:
Post a Comment