Say What??? If the title means nothing to you, you can probably stop reading now. If some of the following is true for you, then this post may be worth your time.
- Your district uses Google Cloud Directory Sync (GCDS) (formally GADS) to upload and sync users between Active Directory and your Google domain.
- You use the ketsEduSystemID AD attribute as your Unique identifier Attribute in GCDS. This has been recommend by KETS and myself in the past.
- You are about to go through the Microsoft Office 365 Divestiture. True for all Kentucky public schools.
If I Described Your District
The name Unique identifier Attribute sums up its purpose. Its a unique ID that doesn’t change. GCDS uses it when updating/creating users. If attributes like a user’s name, email, or location changes, GCDS updates the user info instead of creating a new user because of the unique identifier.
The ketsEduSystemID attribute is populated by OLPS. Sometimes this system has been referred to in the past as the Space Shuttle. After the divestiture, districts won’t use OLPS anymore and the attribute will no longer be populated for new accounts. Therefore, we need to start using a different AD attribute for the Unique identifier Attribute. GCDS recommends the objectGUID AD attribute.
When making this change in GCDS we want to make sure our users are updated rather then having new accounts created. I’ve discussed this with Google support and was told that as long as the user’s email address has not changed since the last time GCDS was run, the Unique identifier Attribute can be updated for the user.
Making The Change
These are the steps I did to change our setup to use the ObjectGUID AD attribute as the Unique identifier Attribute in GCDS. Feel free to use and modify them to work for your district. If you run into specific issues you may want to take a look at the Google Cloud Directory Sync support page. I apologize in advance for the run-on sentences, but I wanted you to have as much information as possible.
1. Temporarily Stop Modifying Active Directory & Google Accounts
- Disable any automated process you use to create/modify accounts in AD.
- Tell AD users not to make any modifications.
- Disable any scripts that automatically run GCDS
- Run GCDS as it is currently setup in order to make any pending changes.
2. Modify The Google Cloud Directory Sync Configuration File
- Make a backup copy of your current GCDS XML configuration file (just in case)
- Open the User Accounts section of GCDS
- Change the Unique identifier Attribute field from ketsEduSystemID to objectGUID
- Save your GCDS config
3. (Optional) Disable The Groups and User Profile Sections
Syncing Groups and User Profiles add more time to the syncing process. They can be temporary skipped for what we are doing.
- Using the same XML config file in GCDS, click the General Settings section
- Uncheck the boxes next to Groups and User Profiles
4. Modify The Configuration File If You Skip Disabled Users
We tell GCDS to skip disabled users when syncing. This has the effect of disabling users’ Google accounts if their account it disabled in AD when GCDS runs. I’ve shared how to set this up at KySTE conferences in the past, so some of you may be doing this. We need to change the Unique identifier Attribute on disabled accounts as well, because if the account is ever re-enabled and a name change occurs prior to GCDS running, a duplicate account could be created. (Better safe than sorry)
This could be changed in GCDS, but in our case I’d have to do it about 120 times so I’m going to do a find and replace using a text editor instead. Personally I use Notepad++.
- Open the XML file GCDS created using your editor of choice.
- Choose Replace. In Notepad++ its under the Search menu
- Search for: (!(userAccountControl:1.2.840.1135184.108.40.2063:=2))
This partial string is what tells GCDS to skip disabled AD accounts.
- Replace the string with nothing. Basically we are just deleting it.
- Save the XML file with a new name. We will only use it once.
5. Run A Simulated Sync
- In GCDS open the config file (if not already open). If you performed Step 4 you need to open the new file.
- Click on the Sync section
- Click on Simulate sync.
6. Review The Logs
- Open the log file
- You should see the primary key will be modified for your users.
- You should not see a lot of created users. If you do make sure that they are valid. In our case, they are a result of not excluding suspended users and are valid.
7. Pull The Trigger
If you are comfortable with the planned changes you see in the log, you are now ready to run GCDS and make the changes.
- In GCDS, click the Sync section
- Click Sync & apply changes
- Once the sync is complete, check the log to make sure the expected changes occurred.
7. Set Config File Back To The New Normal
Now that we have changed the Unique identifier Attribute for our existing users, we need to setup the config XML file to run normally. Depending on what settings you changed, you may or many not have to do each step.
- In GCDS, open your config file
If you changed the code for disabled accounts in step 4, you should open your original config file.
- If you disabled the Groups and User Profile sections in step 3, you need to enable those check boxes in the General Settings section
- Double check that the Unique identifier Attribute field in the User Accounts section is still set to objectGUID
- Save your config file.
8. Test and Enable
Before giving the all clear, test one more time.
- Run a Simulated Sync in the Sync section with the recently saved config file
- Check the created log file
- If log looks normal, click the Sync & apply changes button.
- Check the created log file
- If all looks good, re-enable your automated systems for running GCDS and creating/modifying users in AD
- Give the all clear to those who modify accounts in AD
Hope these directions help you make the necessary changes and that we never have to do this again! 🙂