AD & Office 365: Hard Matching Immutable ID

When do we need to do hard matching? During a migration of users (which already in Office 365) from old domain(AD) to a new domain(AD), and from old AADC to a new AADC.

Why do we need to configure the immutable ID? When a user object is replicated or migrated using ADMT from old domain to new domain, their objectGUID will change and the immutable ID in Office 365 is the old immutable ID from the old domain’s user’s objectGUID. The only impact if you don’t configure the immutable ID, is when you provision the new AADC it will give you an error: “AttributeMustBeUnique”, and will not allow you to sync up to Office 365, until the error has resolved (this part make sure your dirsync duplication feature is true).

What is Immutable ID? Immutable ID is a unique identity(primary key) attribute for Office 365. At the Active Directory, it is called objectGUID. Basically, immutable ID is retrieve from objectGUID. The difference between this ID is their value, objectGUID is converted to a Base64 value for immutable ID.

*To perform hard matching make sure you have Azure module Power Shell installed to your computer. The script given below can be modify if needed.

Here are the steps to successfully complete hard matching;

  1. Disable the directory sync in Office 365
    • Open Azure Power Shell

Connect-MsolService

Set-MsolDirSyncEnabled -EnableDirsync $false

  1. Wait for all users in Office 365 their status change to “in cloud”
    • This takes up 48 hours to 72 hours for the disable to complete
    • *Note: If the specific user’s status is already “in cloud”, don’t have to disable the dirsync.
  2. While waiting for the dirsync to disable, do a ADMT to migrate the user from old domain to the new domain in a target OU.
  3. Next, export csv file with list of users from Office 365 and new domain (user objects): Total csv file: 2
    • Included attributes to export are: User principal name and the object guid (on premise).
    • For O365, just export the user principal name.

#Run this script in the new domain (AD, Windows Power Shell)

#This script is to show user principal name and objectGUID of a user object based on a specific OU

$list = import-csv .\userlist.csv

foreach ($i in $list){

$upn = $i.UPN

$guid = (Get-ADUser -f * {cn -eq $upn} -pr objectguid).objectguid

write-host $guid

}

  1. Copy the objectGUID from the Power Shell and paste into the csv file.
  2. Compare both csv file to eliminate user that is not in the Office 365 csv file.
  3. Finalize the csv file
    • Columns include: user principal name and object guid
  4. Run a power shell to remove the unrelated user from the target OU based on the final csv file (Optional)
    • Reference: https://technet.microsoft.com/en-us/library/ee617206.aspx
  5. Run the following commands to convert the object guid into the new immutable id
  6. Copy and Paste the new immutable id into the finalize csv file
  7. DirSync has completely Disabled, is when the DirSync status in the Office 365 portal is gone.
dirsync
DirSync Status will hide when dirsync has completely disabled

12. At the Azure Power Shell > Remove old immutable id

$users = import-csv .\list.csv -delimiter “,”

foreach ($i in $users)

{

$upn = $i.userprincipalname

Set-MsolUser -userprincipalname $upn -Immutableid “$null”

}

13. Convert the objectGUID to immutable ID

$list = import-csv .\list.csv -delimiter “,”

foreach ($i in $list){
$upn = $i.userprincipalname
$guid = [GUID]$i.objectguid
$bytearray = $guid.tobytearray()
$immutableID = [system.convert]::ToBase64String($bytearray)
write-host $immutableID

}

14. Copy the new immutable id from power shell and paste into the final csv

15. Set new immutable id using the final csv file

$users = import-csv .\list.csv -delimiter “,”

foreach ($i in $users)

{

$upn = $i.userprincipalname

$guid = $i.objectguid

$immutableid = $i.immutableid

Set-MsolUser -userprincipalname $upn -Immutableid $immutableid

}

16. After finishing setting the immutable id,

  • Start back the dirsync

Set-MsolDirSyncEnabled -EnableDirsync $true

17. Run the delta sync at the AADC

Start-ADSyncSyncCycle -PolicyType Delta

18. The End

Reference:

 

Outlook: How to hide “Do Not Forward”

There some customers who are very particular with security and compliance or rights management service. They also would wish to hide all default RMS templates such as, contoso.com – confidential, contoso.com – confidential (View Only) and Do Not Forward, and have their own. Thus, it is easy to hide the contoso.com – confidential and contoso.com – confidential (View Only) templates using the Azure classic portal. However, based on many article I researched on hiding or disable the “Do Not Forward” permission in the Outlook have said “You cannot hide or remove Do Not Forward because it is based on the Office”. So, I came by this article (Reference: https://support.microsoft.com/en-gb/help/2458423/the-message-classification-feature-is-unavailable-when-you-disable-the) to resolve this hiding of “Do Not Forward” feature by modifying the registry of the Office. This method applies to version of Outlook 2010 to Outlook 2016 and can also done via GPO.

Modify using registry;

  1. Open Registry edit (regedit.exe) > HKEY_CURRENT_USER > Software > Microsoft > Office > 16.0 > Common > DRM
  2. Create a new > DWORD(32bit)
  3. Name the registry: DisableDNF
  4. Double click on the registry > enter value ‘1’
  5. Close the registry
  6. Close and relaunch the Outlook

After relaunch the Outlook, you could see whether the given method works is creating a new email > options > permission toggle, the “Do Not Forward” has grey out or disable.

registry
Create a new registry
DisableDNF
Do Not Forward is grey out