UPN Normalization Phase II

Overview

NOTE: I wrote this in early 2014 however I did not publish it until now.

This is a followup to my earlier entry about normalizing the UPN for moving to Office365. This entry covers Phase II which changes the prefix of the UPN, whereas Phase I was to fix the suffix domain of the UPN.

This script will walk AD and change the prefix from whatever it is now to a standard. It looks at the primary SMTP address attribute and uses that as the source to set the UPN. This way the UPN and primary SMTP match best they can. In my environment we do have several people who instead of having @mycompany.com they have @mycompany.com.countrycode as their email domain. This pulls just the prefix from that attribute.

Solution

You will need to modify lines 2, 12, 29, and 30.

Line 2 is a limit to how many changes per run to make. I would run the script every day and let it change 5000 at a time. During initial test runs I was doing about 100 at a time.

Line 12 will need the LDAP query updated for your domain.

Line 28 and 29 just need @mycompany.com to be set to your domain from Phase I.

You can also comment out line 36 to do a test run.

When ran, it will spit out a log file in the scripts directory stating what it did as shown below.

 Updating [email protected] to [email protected]  
 Updating [email protected] to [email protected]  
 Updating johno'[email protected] to [email protected]  

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 Cory's Phase II script here. 

-Kevin Fason

Static IP in SCCM Task Sequence

Overview

There have been some scenarios were we have to set a static IP for imaging as we don't have DHCP on that VLAN. MDT does this automatically, however SCCM does not so we came up with a way of handling this scenario.

Solution

This script below is ran very early in the TS, anywhere before the first restart really. It will take the data entered on the Wizard and create variables for the settings so its used later. It also will log it out.

NOTE: I don't recall if I had this written or if it came from another source. Credit where credit is due if its yours.

When you boot up the OSD PE you can select 'Configure Network Settings' on the initial wizard and enter in relevant network information. I would suggest you just do the first interface. This script will in turn populate the following built in variables (complete list) that are used by the TS engine. 

• OSDAdapter0DNSServerList:x.x.x.x
• OSDAdapter0EnableDHCP:False
• OSDAdapter0Gateways:x.x.x.x
• OSDAdapter0IPAddressList:x.x.x.x
• OSDAdapter0SubnetMask:x.x.x.x

I would advise to only use the first NIC as some TS parts do not support multiple NICs so those can get setup later. Servers usually have NIC teaming once its deployed so that has to be setup post deployment.

just create a step that runs 'cscript.exe SetStaticIPInTaskSequence.vbs' from the package its in.

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 the static IP script here.

-Kevin Fason

UPN Normalization Phase I

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.

Issue

So whats the issue?  In my AD investigation I found over 14 different syntaxes for the UPN. Some examples being:

• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]

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.

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.

-Kevin Fason