Malware Filter Policy Updates in Office 365

Posted on Leave a commentPosted in EOP, exchange online, Exchange Online Protection, malware, Office 365

In March I wrote a blog post that showed how to take the attachment filter list from Edge Server and add those attachment block types to EOP, as EOP had a very small list of attachments.

Today on one of my client tenants I noticed this precanned list of attachment extension types is now at 96 items, which is a considerable change from the list back in March 2017. The list in March was ace, ani, app, docm, exe, jar, reg, scr, vbe, vbs and still is for some tenants at the time of writing.

But while Microsoft has added new attachment types to the picker UI, there was no notification to the end client administrators that they might want to update their MalwareFilterPolicy to take account of these new attachment types that Microsoft have considered worthy of being blocked.

Therefore, now is the time to check your existing MalwareFilterPolicy to include the new extension types (listed below).

For reference, the new attachment filter types that have been added since March 2017 are asp,cer,der,dll,dos,gadget,Hta,Inf,Ins,Isp,Its,Jse,Ksh,Lnk,mad,maf,mag,mam,maq,mar,mas,mat,mau,mav,maw,msh,msh1,msh1xml,msh2,msh2xml,mshxml,obj,os2,plg,pst,rar,tmp,vsmacros,vsw,vxd,w16,ws

But notice that some of these are initial capital versions of entries that are already there (i.e. hta was in the list or on Edge server a few months ago, but now Hta is on the list as well).

I am assuming attachment blocking is not case sensitive and so the following extensions are if added from the attachment list picker will be duplicates – Hta, Inf, Ins, Jse, Ksh.

OWA and Conditional Access: Inconsistent Error Reports

Posted on 1 CommentPosted in AzureAD, conditional access, EM+S, enterprise mobility + security, exchange, exchange online, Exchange Online Protection, IAmMEC, Outlook

Here is a good error message. Its good, because I could not find any references to it on Google and the fault was nothing to do with the error message:

image

The error says “something went wrong” and “Ref A: a long string of Hex Ref B: AMSEDGE0319 Ref C: Date Time”. The server name in Ref B will change as well. It also says “more details” and if you click that there are no more details, but that text changes to “fewer details”. As far as I have seen, this only appears on Outlook Web Access (OWA).

The error appears under these conditions:

  1. You are enabled for Enterprise Mobility + Security licences in Azure AD
  2. Conditional Access rules are enabled
  3. The device you are on, or the location you are at etc (see the specifics of the conditional access rule) mean that you are outside the conditions allowed to access Outlook Web Access
  4. You browsed directly to https://outlook.office.com or https://outlook.office365.com

What you see in the error message is OWA’s way of telling you that you cannot get to that site from where you are. That you have failed the conditional access tests.

On the other hand, if you visit the Office 365 portal or MyApps (https://portal.office.com or https://myapps.microsoft.com) and click the Mail icon in your Office 365 menu or on the portal homepage then you get a page that says (in the language of your browser):

image or in Welsh, image

This says “you can’t get there from here” and the reasons why you have failed conditional access.

If you were on a device or location that allowed you to connect (such as a device managed by Intune and compliant with Intune rules) then going to OWA directly will work, as will going via the menu.

So how can you avoid this odd error message for your users. For this, you need to replace outlook.office.com with your own custom URL. For OWA you can create a DNS CNAME in your domain for (lets say) webmail that points to outlook.office365.com (for this it will not work if you point the CNAME to outlook.office.com). Your users can now go to webmail.yourdomain.com. This will redirect the user via Azure AD for login and token generation, and as you are redirected via Azure AD you will always see the proper, language relevant, conditional access page.

Administrators, AADConnect and AdminSDHolder Issues (or why are some accounts having permission-issue)

Posted on 1 CommentPosted in AADConnect, AADSync, active directory, AdminSDHolder, dirsync, exchange, exchange online, hybrid, Office 365

AdminSDHolder is something I come across a lot, but find a lot of admins are unaware of it. In brief it is any user that is a member of a protected group (i.e. Domain Admins) will find that their AD permission inheritance and access control lists on their AD object will be reset every hour. Michael B. Smith did a nice write-up on this subject here.

AdminSDHolder is an AD object that determines what the permissions for all protected group members need to be. Why this matters with AADConnect and your sync to Azure Active Directory (i.e. the directory used by Office 365) is that any object that the AADConnect service cannot read cannot be synced, and any object that the AADConnect service cannot write to can be targeted by writeback permissions. This blog post was last updated 18th June 2017 in advance of the release of AADConnect version 1.1.552.0.

For the read permissions this is less of an issue, as the default read permissions by every object is part of a standard Active Directory deployment and so you will find that AdminSDHolder contains this permission and therefore protected objects can be read by AADConnect. This happens in reality becase Authenticated Users have read permissions to lots of attributes on the AdminSDHolder object under the hidden System containing in the domain. Unless your AD permissions are very locked down or AdminSDHolder permissions have been changed to remove Authenticated Users you should have no issue in syncing admin accounts, who of course might have dependencies on mailboxes and SharePoint sites etc. and so need to be synced to the cloud.

Writeback though is a different ball game. Unless you have done AADConnect with Express settings you will find that protected accounts fail during the last stage of AADConnect sync process. You often see errors in the Export profile for your Active Directory that list your admin accounts. Ofter the easiest way to fix this is to enable the Inheritance permission check box on the user account and sync again. The changes are now successfully written but within the hour this inheritance checkbox will be removed and the default permissions as set on AdminSDHolder reapplied to these user accounts. Later changes that need written back from the cloud will result in a failure to writeback again, and again permission issues will be to blame.

To fix this we just need to ensure that the AdminSDHolder object has the correct permissions needed. This is nothing more than doing what the AADConnect Express wizard will do for you anyway, but if you don’t do the Express wizard I don’t think I have seen what you should do documented anywhere – so this is the first (maybe).

Often if you don’t run Express settings you are interested in the principal of least privilege and so the rest of this blog post will outline what you will see in your Active Directory and what to do to ensure protected accounts will always sync and writeback in the Azure Active Directory sync engine. I covered the permissions to enable various types of writeback permissions in a different blog post, but the scripts in this post never added the correct write permissions to AdminSDHolder, so this post will cover what to do for your protected accounts.

First, take a look at any protected account (i.e. one that is a member of Domain Admins):
image

You will see in the Advanced permissions dialog that their is an “Enable Inheritance” button (or a check box is unchecked in older versions of Active Directory. You will also notice that all the permissions under the “Inherited From” column read “None” – that is there are no permissions inherited. You will also see, as shown in the above dialog, that if Express settings have been run for your AADConnect sync service that a access control entry for the AADConnect service account will be listed – here this is MSOL_924f68d9ff1f (yours will be different if it exists) and has read/write for everything. This is not least privilege! If you have run the sync engine previously on different servers and later removed them (as the sync engine can only run on one server to one AAD tenant, excluding staging servers) then you might see more than one MSOL account. The description field of the account will show what server it was created on for your information.

If you compare your above admin account to a non-protected account you will see inheritance can be disabled and that the Inherited From column lists the source of the permission inheritance.

Compare the access control entries (ACE) to the list of ACE’s on the AdminSDHolder object. AdminSDHolder can be found at CN=AdminSDHolder,CN=System,DC=domain,DC=local. You should find that the protected accounts match those of the AdminSDHolder, or at least will within the hour as someone could have just changed something.

Add a permission ACE to AdminSDHolder and it will appear on each protected account within an hour, remove an ACE and it will go within the hour as well. So you could for example remove the MSOL_ account(s) from older ADSync deployments and tidy up your permissions as well.

This is what my Advanced permissions for AdminSDHolder looks like on my domain

image

If I add the relevant ACE’s here for the writeback permissions then within the hour, and then for syncs that happen after that time, the errors for writeback in the sync management console will go away. Note though that AdminSDHolder is per domain, so if you are syncing more than one domain you need to set these permissions on each domain.

To script these permissions, run the following in PowerShell to update AD permissions regarding to the different hybrid writebacks scenarios that you are interested in implementing.

Finding All Your AdminSDHolder Affected Users

The following PowerShell will let you know all the users in your domain who have an AdminCount set to 1 (>0 in reality), which means they are impacted by AdminSDHolder restrictions. The changes below directly on the AdminSDHolder will impact these users as their permissions will get updated to allow writeback from Azure AD.

get-aduser -Filter {admincount -gt 0} -Properties adminCount -ResultSetSize $null | FT DistinguishedName,Enabled,SamAccountName

SourceAnchor Writeback

This setting is needed for all installations since version 1.1.552.0.

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is an account usually in the form of AAD_number or MSOL_number].
$AdminSDHolder = "CN=AdminSDHolder,CN=System,DC=contoso,DC=com"

$cmd = "dsacls.exe '$AdminSDHolder' /G '`"$accountName`":WP;ms-ds-consistencyGuid'"
Invoke-Expression $cmd | Out-Null

Password Writeback

The following PowerShell will modify the permissions on the AdminSDHolder object so that protected accounts can have Self Service Password Reset (SSPR) function against the accounts. Note you need to change the DC values in the script for it to function against your domain(s).

To determine the account name that permissions must be granted to, open the Synchronization Service Manager on the sync server, click Connectors and double click the connector to the domain you are updating. Under the Connect to Active Directory Forest item you will see the Forest Name and User Name. The User Name is the name of the account you need in the script. An example is shown below:

image

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is an account usually in the form of AAD_number or MSOL_number].
$AdminSDHolder = "CN=AdminSDHolder,CN=System,DC=contoso,DC=com"

$cmd = "dsacls.exe '$AdminSDHolder' /G '`"$accountName`":CA;`"Reset Password`"'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls.exe '$AdminSDHolder' /G '`"$accountName`":CA;`"Change Password`"'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls.exe '$AdminSDHolder' /G '`"$accountName`":WP;lockoutTime'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls.exe '$AdminSDHolder' /G '`"$accountName`":WP;pwdLastSet'"
Invoke-Expression $cmd | Out-Null

Exchange Hybrid Mode Writeback

The below script will set the permissions required for the service account that AADSync uses. Note that if Express mode has been used, then an account called MSOL_AD_Sync_RichCoexistence will exist that has these permissions rather than being assigned directly to the sync account. Therefore you could change the below permissions to utilise MSOL_AD_Sync_RichCoexistence rather than AAD_ or MSOL_ and achieve the same results, but knowing that future changes to the MSOL_ or AAD_ account will be saved as it was done via a group.

The final permission in the set is for msDS-ExternalDirectoryObjectID and this is part of the Exchange Server 2016 (and maybe Exchange Server 2013 later CU’s) schema updates. Newer documentation on AAD Connect synchronized attributes already has this attribute listed, for example in Azure AD Connect sync: Attributes synchronized to Azure Active Directory

$accountName = "domain\aad_account"
$AdminSDHolder = "CN=AdminSDHolder,CN=System,DC=contoso,DC=com"

$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;proxyAddresses'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;msExchUCVoiceMailSettings'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;msExchUserHoldPolicies'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;msExchArchiveStatus'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;msExchSafeSendersHash'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;msExchBlockedSendersHash'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;msExchSafeRecipientsHash'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;msDS-ExternalDirectoryObjectID'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /G '`"$accountName`":WP;publicDelegates'"
Invoke-Expression $cmd | Out-Null

Once these two scripts are run against AdminSDHolder object and you wait an hour, the permissions will be applied to your protected accounts, then within 30 minutes (based on the default sync time) any admin account that is failing to get cloud settings written back to Active Directory due to permission-issue errors will automatically get resolved.

Exchange Edge Server and Common Attachment Blocking In Exchange Online Protection

Posted on Leave a commentPosted in 2007, 2010, 2013, 2016, Edge, EOP, exchange, exchange online, Exchange Online Protection, FOPE, IAmMEC, Office 365

Both Exchange Server Edge role and Exchange Online Protection have an attachment filtering policy. The default in Edge Server is quite long, and the default in EOP is quite short. There is also a few values that are common to both.

So, how do you merge the lists so that your Edge Server attachment filtering policy is copied to Exchange Online in advance of changing your MX record to EOP?

You run

Set-MalwareFilterPolicy Default -FileTypes ade,adp,cpl,app,bas,asx,bat,chm,cmd,com,crt,csh,exe,fxp,hlp,hta,inf,ins,isp,js,jse,ksh,lnk,mda,mdb,mde,mdt,mdw,mdz,msc,msi,msp,mst,ops,pcd,pif,prf,prg,ps1,ps11,ps11xml,ps1xml,ps2,ps2xml,psc1,psc2,reg,scf,scr,sct,shb,shs,url,vb,vbe,vbs,wsc,wsf,wsh,xnk,ace,ani,docm,jar

This takes both the Edge Server default list and the EOP default list, minus the duplicate values and adds them to EOP. If you have a different custom list then use the following PowerShell to get your two lists and then use the above (with “Default” being the name of the policy) PowerShell to update the list in the cloud

Edge Server: Get-AttachmentFilterEntry

EOP: $variable = Get-MalwareFilterPolicy Default
$variable.FileTypes

Get-SpoofMailReport in EOP

Posted on Leave a commentPosted in EOP, exchange online, Exchange Online Protection, Office 365, spam, spoof

Using Office 365 or EOP to protect your email and worried about spoofed emails? Then try this cmdlet in Remote PowerShell for EOP:

PS C:\Users\brian.reid> Get-SpoofMailReport

Date                Event Type Direction Domain Action       Spoofed Sender              True Sender     Sender IP
—-                ———- ——— —— ——       ————–              ———–     ———
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     no-reply@domain.com         mandrillapp.com 198.2.186.0/24
18/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com          mimecast.com    1.130.217…
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com                          1.130.217…
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     no-reply@domain.com         someapp.com     198.2.179.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     paul@domain.com             mimecast.com    1.130.217…
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com                       1.130.217…
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com                       1.130.217…
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com                       1.130.217…
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com          mimecast.com    91.220.42.0/24
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com                          91.220.42.0/24
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
18/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com                          1.130.217…
18/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com          mimecast.com    91.220.42.0/24
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     paul@domain.com             mimecast.com    91.220.42.0/24
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com          mimecast.com    1.130.217…
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     paul@domain.com                             1.130.217…
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     paul@domain.com                             91.220.42.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     paul@domain.com             mimecast.com    91.220.42.0/24
10/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com                          1.130.217…
11/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com                          1.130.217…
11/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@domain.co.uk                      1.130.217…
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
18/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     paul@domain.com                             91.220.42.0/24
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     no-reply@domain.com         mandrillapp.com 198.2.132.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     andrew@domain.com           mimecast.com    91.220.42.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com          mimecast.com    91.220.42.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com                          91.220.42.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.co.uk     mimecast.com    1.130.217…
10/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
10/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@other.com                         1.130.217…
11/04/2016 00:00:00 SpoofMail  Inbound          CaughtAsSpam wordpress@other.com         host-h.net      129.232.144…
11/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@domain.co.uk      mimecast.com    91.220.42.0/24
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@domain.co.uk      mimecast.com    91.220.42.0/24
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@other.com         host-h.net      197.189.237…
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@other.com                         91.220.42.0/24
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     no-reply@domain.com         mandrillapp.com 198.2.187.0/24
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.co.uk                     1.130.217…
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@other.com         host-h.net      197.189.237…
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@other.com                         91.220.42.0/24
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.co.uk     mimecast.com    1.130.217…
17/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@domain.co.uk      mimecast.com    1.130.217…
17/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com                          1.130.217…
17/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
17/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@domain.co.uk      mimecast.com    91.220.42.0/24
17/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24
18/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com                          91.220.42.0/24
18/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24

Thats the output I get from running this on the afternoon of April 20th (UK style dates for the American readers of this blog)! Notice a few things (its been somewhat redacted to remove private into), but the spam filter provider in front of EOP in this tenant is seen as spoofing postmaster emails and there are some from mandrillapp.com in a similar vein. Both of these companies send email on our behalf, so I expect to see them here – so nothing to see here for these. How about the others? One is a hosting company, probably hosting WordPress instances and so these are probably alerts of some kind from a web hoster to us, so again I think for us nothing here.

What do you get – is it more interesting for you?

Then finally, how about getting the results in date order, as they are not by default: Get-SpoofMailReport | sort -Property Date

 

 

Renewing Apple APN for Office 365 Mobile Device Management

Posted on 3 CommentsPosted in exchange online, iOS, iPad, iPhone, MDM, Mobile Device Management, mobile phones, Office 365

Office 365 MDM (Mobile Device Management) allows you to manage iOS based Apple devices. Once you have had Office 365 Mobile Device Management is use for a year, the Apple APN certificate that you would have created a year ago for this purpose will expire. If you did not add this renewal date to your calendar when you set up Office 365 MDM, or if you have taken over as administrator from someone else since then you had best check for your renewal dates, as Apple will email the address they have for the certificate at 30 days, 10 days and the day before it expires. Here is the day before it expires email warning – and I got this yesterday. So I had better renew the certificate now then. You of course will not leave it so late!

image

To check your renewal date, login as a Global Admin to the Office 365 Portal. On the old portal visit the Mobile Management tab on the left and the renewal date is shown on the right:

SNAGHTMLe083076

The above is for one of my clients, and the 30 day warning arrived for them today – so I will do them in a few days time.

If you are using the new Office 365 admin portal, then expand Resources > Mobile Management on the left navigation bar (note, at the time of writing, you cannot renew your APNs from the new portal and must use the old – the new portal redirects you back to your starting page all the time and does not start the correct wizard). This opens the same window as shown above. Later versions of the new portal might integrate the page with the portal, but that is not currently active (April 2016):

SNAGHTMLe0b34ae

To renew your certificate click the Manage settings link under the APNs Certificate for iOS devices message to the top right.

You will see the “Set up mobile device management” page:

image

Click Set up to the right of the “Configure an APNs Certificate for iOS devices”. This takes you to the “Install Apple Push Notification Certificate” page. On one of my tenants (possibly with the APNs expired already) clicking Set up took me back to the “Mobile Device Management for Office 365” and I could never get past it. That tenant needed a support call raised to fix.

On the “Install Apple Push Notification Certificate” page click “Download your CSR file” and save the file somewhere you can find shortly.

SNAGHTMLe183115

Click Next once file saved to disk.

SNAGHTMLe1a0325

On the second page of the wizard, click the “Apple APNS Portal” link. As this is a renewal, you need to login to the Apple Developer site with the same credentials used last time. If you have lost these and cannot reset them, then I suspect uploading a new certificate issued to a new ID will work, but I have not tested this.

SNAGHTMLe1cb6db

Once signed in click Renew. If changing issuer account and you have access to the old account, then click Revoke and login with the new account to https://identity.apple.com/pushcert to generate the new APNs certificate.

SNAGHTMLe1eb134

On the Renewal page, upload the saved CSR file from step 1 into the “Vendor-Signed Certificate Signing Request” and click Upload:

SNAGHTMLe1fdded

If you get a prompt about opening or saving a file called renew.json then cancel it and refresh the web browser page to continue the CSR file upload. The Apple web site often issues a JSON file as a download, but that should not happen and is not the file you need. Once the APNs is ready the browser will change back to the Apple Push Certificates Portal home page with a new certificate present (confirm this as the date will be a year from today). Click Download to get the APNs file.

SNAGHTMLe27d904

Upon clicking download you are offered to save a .pem file. This file will be called “MDM_ Microsoft Corporation_Certificate.pem”. If you are a Microsoft Partner and are doing this for multiple customers then rename it to suit the end client.

Close the Apple Push Certificates Portal page and in the previous tab you will find yourself back at step 2. Click Next.

SNAGHTMLe2a4532

In the file upload field, browse for MDM_ Microsoft Corporation_Certificate.pem (or whatever you renamed it to) and upload it to Office 365. The certificate is automatically uploaded. Click Finish and you are done.

Don’t forget to add a calendar appointment for this time next year just in case the reminders from Apple don’t reach you.

Exchange Online Archive–Counting Archives

Posted on Leave a commentPosted in archive, exchange, exchange online, Exchange Server, EXO, IAmMEC, Office 365

If you are using Exchange Online Archive and what to get a count of the number of users with an archive, or a list of the users with an archive, then the following PowerShell scripts will give you this info:

List all users with an Exchange Online Archive:

Get-MailUser -ResultSize Unlimited | where {$_.ArchiveName -ilike “In-Place Archive*”}

Count all users with an Exchange Online Archive:

(Get-MailUser -ResultSize Unlimited | where {$_.ArchiveName -ilike “In-Place Archive*”}).Count

Both of these PowerShell cmdlets need to be run in Exchange Online via Remote PowerShell.

Unable To Remove Office 365 Domain Error

Posted on Leave a commentPosted in dirsync, exchange online, hybrid, IAmMEC, MSOL, Office 365, powershell

If you need to remove a domain from Office 365 it needs to not be in use. This includes the services that use that domain, for example an Accepted Domain in Exchange Online. If though you have an expired, maybe test, Office 365 tenant and you want to remove a domain from it you may find unhelpful error messages. For example I have seen in the domain removal process in the portal a message saying “Please don’t close this page while we remove your domain” etc. It tries for several minutes as it predicts, but did not complete:

image

Upon failing to complete you get a further warning before it finally gives up and tells you that it cannot complete:

image

So the obvious next step (or obvious to me anyway) is to try the removal in remote PowerShell to Office 365. The cmdlet is Remove-MsolDomain -DomainName domain.com but this comes back with with messages that might be helpful, but after repeated running of the cmdlet and fixing the error still suggests the same fix.

image

The error reads: Remove-MsolDomain : Unable to remove this domain. Use Get-MsolUser -DomainName <domain name>  to retrieve a list  of objects that are blocking removal. The problem with this error is the list of objects here are only user accounts and not any of the other objects that could block a domain removal.

So sure, remove your unneeded users or change their UPN/email address to not include this domain that you want to remove, but also run Get-MsolContact and Get-MsolGroup and then remove or edit the contacts and the groups that use this domain.

So though the error says to fix the user objects that are blocking domain removal, you also need to fix or remove the groups and contacts as well.

Exchange Server and Missing Root Certificates

Posted on Leave a commentPosted in 2007, 2010, 2013, exchange, exchange online, Exchange Server, federation, Free/Busy

I came across an issue with a clients Exchange Server deployment today that is not well documented – or rather it is, but you need to know where to look. So I thought I would document the troubleshooting steps and the fix here.

We specifically came across this error when testing Free/Busy for an Office 365 migration, though it could happen for a variety of reasons. Free/Busy and other lookups in a cross-forest Exchange Server deployment require a working organization configuration and this was failing. Running Test-FederationTrust (a prerequisite of the organization relationship) in verbose mode (add -Verbose to the end) returned the following:

Unable to retrieve federation metadata from the security token
service. Reason: Microsoft.Exchange.Management.FederationProvisioning.FederationMetadataException: Unable to access the
Federation Metadata document from the federation partner. Detailed information: “The underlying connection was closed:
Could not establish trust relationship for the SSL/TLS secure channel.”.

The final result of the test will also show two errors for “Unable to retrieve federation metadata from the security token service.” and “Failed to request delegation token.”

The last part of the verbose error is the clue here. The server in question is unable to make an SSL/TLS connection to the endpoint that the federation trust needs to reach to get the federation trust metadata. That endpoint is listed right at the start of the Verbose output. It reads:

VERBOSE: [16:53:08.306 GMT] Test-FederationTrust : Requesting Federation Metadata from
https://nexus.microsoftonline-p.com/FederationMetadata/2006-12/FederationMetadata.xml.

Now that we have a URL and an error message, check that the URL is reachable from each of your Exchange Servers. At my client today we found one server could not successfully reach this endpoint without an SSL error turning up in the browser. The problem was that the certificate that the endpoint is secure with is issued by the Baltimore Cybertrust Root Certificate – one that Microsoft uses for lots of services, but the root certificate was not installed on that machine. Lots of root certs where missing from that machine as it had never had a root certificate update applied to it.

We installed the latest Root Certificate Update and then the federation trust worked and free/busy etc. (mail tips, cross-forest message tracking etc.) all worked fine.

Configuring Writeback Permissions in Active Directory for Azure Active Directory Sync

Posted on 34 CommentsPosted in 2008, 2008 R2, 2012, 2012 R2, active directory, ADFS 3.0, Azure, Azure Active Directory, cloud, exchange, exchange online, groups, hybrid, IAmMEC, Office 365, WAP, Web Application Proxy, windows

[Update March 2017 – added another blog post on using the below to fix permission-issue errors on admin and other protected accounts at http://c7solutions.com/2017/03/administrators-aadconnect-and-adminsdholder-issues]

[This blog post was last updated 18th June 2017 in advance of the release of AADConnect version 1.1.552.0. This post contains updates to the below scripts to include the latest attributes synced back to on-premises]

Azure Active Directory has been long the read-only cousin of Active Directory for those Office 365 and Azure users who sync their directory from Active Directory to Azure Active Directory apart from eight attributes for Exchange Server hybrid mode. Not any more. Azure Active Directory writeback is now available and in preview for some of the writeback types at the time of writing. This enabled objects to be mastered or changed in Azure Active Directory and written back to on-premises Active Directory.

This writeback includes:

  • Devices that can be enrolled with Office 365 MDM or Intune, which will allow login to AD FS controlled resources based on user and the device they are on
  • “Modern Groups” in Office 365 can be written back to on-premises Exchange Server 2013 CU8 or later hybrid mode and appear as mail enabled distribution lists on premises. Does not require AAD Premium licences
  • Users can change their passwords via the login page or user settings in Office 365 and have that password written back online.
  • Exchange Server hybrid writeback is the classic writeback from Azure AD and is the apart from Group Writeback is the only one of these writebacks that does not require Azure AD Premium licences.
  • User writeback from Azure AD (i.e. users made in Office 365 in the cloud for example) to on-premises Active Directory
  • Windows 10 devices for “Azure AD Domain Join” functionality

All of these features (apart from Exchange Hybrid writeback) require AADSync and not DirSync. Install and run the AADConnect program to migrate from DirSync to AADSync and then in the Synchronization Options on rerunning the AADConnect wizard you can add all these writeback functions.

SourceAnchor Writeback

For users with (typically) multi-forest deployments or plans or a forest migration, the objectGuid value in Active Directory, which is used as the source for the attribute that keys your on-premises object to your synced cloud object – in AAD sync parlance, this is known as the SourceAnchor. If you set up AADConnect version 1.1.552.0 or later you can opt to change from objectGuid to a new source anchor attribute known as ms-ds-consistencyGuid. To be able to use this new feature you need the ability for AADConnect connector account to be able to read ObjectGUID and then write it back to ms-ds-consistencyGuid. The read permissions are typically available to the connector account without doing anything special, and if AADConnect is installed in Express Mode it will get the write permissions it needs, but as with the rest of this blog, if you are not using Express Mode you need to grant the permissions manually and so write permissions are needed to the ms-ds-consistencyGuid attribute. This can be done with this script.


$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is an account in the form of AAD_number].
$ForestDN = "DC=contoso,DC=com"

$cmd = "dsacls '$ForestDN' /I:S /G '`"$accountName`":WP;ms-ds-consistencyGuid;user'"
Invoke-Expression $cmd | Out-Null

Note that if you use ms-ds-consistencyGuid then there are changes required on your ADFS deployment as well. The Issuance Transform Rules for the Office 365 Relying Party Trust contains a rule that specifies the ImmutableID (aka AADConnect SourceAnchor) that the user will be identified as for login. By default this is set to ObjectGUID, and if you use AADConnect to set up ADFS for you then the application will update the rule. But if you set up ADFS yourself then you need to update the rule.

Issuance Transform Rules

When Office 365 is configured to federate a domain (use ADFS for authentication of that domain and not Azure AD) then the following are the claims rules that exist out of the box need to be adjusted. This is to support the use of ms-ds-consistencyguid as the immutable ID.

ADFS Management UI > Trust Relationships > Relying Party Trusts

Select Microsoft Office 365 Identity Platform > click Edit Claim Rules

You get two or three rules listed here. You get three rules if you use -SupportMultipleDomain switch in Convert-MSOLDomainToFederated.
Rule 1:
Change objectGUID to ms-DS-ConsistencyGUID
Rule Was:
c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”]
=> issue(store = “Active Directory”, types = (“http://schemas.xmlsoap.org/claims/UPN”, “http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID”), query = “samAccountName={0};userPrincipalName,objectGUID;{1}”, param = regexreplace(c.Value, “(?<domain>[^\\]+)\\(?<user>.+)”, “${user}”), param = c.Value);
New Value:
c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”]
=> issue(store = “Active Directory”, types = (“http://schemas.xmlsoap.org/claims/UPN”, “http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID”), query = “samAccountName={0};userPrincipalName,ms-DS-ConsistencyGUID;{1}”, param = regexreplace(c.Value, “(?<domain>[^\\]+)\\(?<user>.+)”, “${user}”), param = c.Value);

Preparing for Device Writeback

If you do not have a 2012 R2 or later domain controller then you need to update the schema of your forest. Do this by getting a Windows Server 2012 R2 ISO image and mounting it as a drive. Copy the support/adprep folder from this image or DVD to a 64 bit domain member in the same site as the Schema Master. Then run adprep /forestprep from an admin cmd prompt when logged in as a Schema Admin. The domain member needs to be a 64 bit domain joined machine for adprep.exe to run.

Wait for the schema changes to replicate around the network.

Import the cmdlets needed to configure your Active Directory for writeback by running Import-Module ‘C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1’ from an administrative PowerShell session. You need Azure AD Global Admin and Enterprise Admin permissions for Azure and local AD forest respectively. The cmdlets for this are obtained by running the Azure AD Connect tool.


$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is an account in the form of AAD_number].
Initialize-ADSyncDeviceWriteBack -AdConnectorAccount $accountName -DomainName contoso.com #[domain where devices will be created].

This will create the “Device Registration Services” node in the Configuration partition of your forest as shown:

image

To see this, open Active Directory Sites and Services and from the View menu select Show Services Node. Also in the domain partition you should now see an OU called RegisteredDevices. The AADSync account now has permissions to write objects to this container as well.

In Azure AD Connect, if you get the error “This feature is disabled because there is no eligible forest with appropriate permissions for device writeback” then you need to complete the steps in this section and click Previous in the AADConnect wizard to go back to the “Connect your directories” page and then you can click Next to return to the “Optional features” page. This time the Device Writeback option will not be greyed out.

Device Writeback needs a 2012 R2 or later AD FS server and WAP to make use of the device info in the Active Directory (for example, conditional access to resources based on the user and the device they are using). Once Device Writeback is prepared for with these cmdlets and the AADConnect Synchronization Options page is enabled for Device Writeback then the following will appear in Active Directory:

image

Not shown in the above, but adding the Display Name column in Active Directory Users and Computers tells you the device name. The registered owner and registered users of the device are available to view, but as they are SID values, they are not really readable.

If you have multiple forests, then you need add the SCP record for the tenant name in each separate forest. The above will do it for the forest AADConnect is installed in and the below script can be used to add the SCP to other forests:

$verifiedDomain = "contoso.com"  # Replace this with any of your verified domain names in Azure AD
$tenantID = "27f998bf-86f2-41bf-91ab-2d7ab011df35"  # Replace this with you tenant ID
$configNC = "CN=Configuration,DC=corp,DC=contoso,DC=com"  # Replace this with your AD configuration naming context
$de = New-Object System.DirectoryServices.DirectoryEntry
$de.Path = "LDAP://CN=Services," + $configNC
$deDRC = $de.Children.Add("CN=Device Registration Configuration", "container")
$deDRC.CommitChanges()
$deSCP = $deDRC.Children.Add("CN=62a0ff2e-97b9-4513-943f-0d221bd30080", "serviceConnectionPoint")
$deSCP.Properties["keywords"].Add("azureADName:" + $verifiedDomain)
$deSCP.Properties["keywords"].Add("azureADId:" + $tenantID)
$deSCP.CommitChanges()

Preparing for Group Writeback

Writing Office 365 “Modern Groups” back to Active Directory on-premises requires Exchange Server 2013 CU8 or later schema updates and servers installed. To create the OU and permissions required for Group Writeback you need to do the following.

Import the cmdlets needed to configure your Active Directory for writeback by running Import-Module ‘C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1’ from an administrative PowerShell session. You need Domain Admin permissions for the domain in the local AD forest that you will write back groups to. The cmdlets for this are obtained by running the Azure AD Connect tool.

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is an account usually in the form of AAD_number].
$cloudGroupOU = "OU=CloudGroups,DC=contoso,DC=com"
Initialize-ADSyncGroupWriteBack -AdConnectorAccount $accountName -GroupWriteBackContainerDN $cloudGroupOU

Once these cmdlets are run the AADSync account will have permissions to write objects to this OU. You can view the permissions in Active Directory Users and Computers for this OU if you enable Advanced mode in that program. There should be a permission entry for this account that is not inherited from the parent OU’s.

At the time of writing, the distribution list that is created on writeback from Azure AD will not appear in the Global Address List in Outlook etc. or allow on-premises mailboxes to send to these internal only cloud based groups. To add it to the address book you need to create a new subdomain, update public DNS and add send connectors to hybrid Exchange Server. This is all outlined in https://technet.microsoft.com/en-us/library/mt668829(v=exchg.150).aspx. This ensure’s that on-premises mailboxes can deliver to groups as internal senders and not require external senders enabled on the group. To add the group to the Global Address List you need to run Update-AddressList in Exchange Server. Once group writeback is prepared for using these cmdlets here and AADConnect has had it enabled during the Synchronization Options page, you should see the groups appearing in the selected OU as shown:

image

And you should find that on-premises users can send email to these groups as well.

Preparing for Password Writeback

The option for users to change their passwords in the cloud and have then written back to on-premises (with multifactor authentication and proof of right to change the password) is also available in Office 365 / Azure AD with the Premium Azure Active Directory or Enterprise Mobility Pack licence.

To enable password writeback for AADConnect you need to enable the Password Writeback option in AADConnect synchronization settings and then run the following three PowerShell cmdlets on the AADSync server:


Get-ADSyncConnector | fl name,AADPasswordResetConfiguration
Get-ADSyncAADPasswordResetConfiguration -Connector "contoso.onmicrosoft.com - AAD"
Set-ADSyncAADPasswordResetConfiguration -Connector "contoso.onmicrosoft.com - AAD" -Enable $true

The first of these cmdlets lists the ADSync connectors and the name and password reset state of the connector. You need the name of the AAD connector. The middle cmdlet tells you the state of password writeback on that connector and the last cmdlet enables it if needed. The name of the connector is required in these last two cmdlets.

To set the permissions on-premises for the passwords to be written back the following script is needed:

$passwordOU = "DC=contoso,DC=com" #[you can scope this down to a specific OU]
$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is an account usually in the form of AAD_number].

$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":CA;`"Reset Password`";user'"
Invoke-Expression $cmd | Out-Null

$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":CA;`"Change Password`";user'"
Invoke-Expression $cmd | Out-Null

$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":WP;lockoutTime;user'"
Invoke-Expression $cmd | Out-Null

$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":WP;pwdLastSet;user'"
Invoke-Expression $cmd | Out-Null

Finally you need to run the above once per domain.

Preparing for Exchange Server Hybrid Writeback

Hybrid mode in Exchange Server requires the writing back on eight attributes from Azure AD to Active Directory. The list of attributes written back is found here. The following script will set these permissions for you in the OU you select (or as shown at the root of the domain). The DirSync tool used to do all this permissioning for you, but the AADSync tool does not. Therefore scripts such as this are required. This script sets lots of permissions on these eight attributes, but for clarify on running the script the output of the script is sent to Null. Remove the “| Out-Null” from the script to see the changes as they occur (the script also takes a lot longer to run).

$accountName = "domain\aad_account"
$HybridOU = "DC=contoso,DC=com"

#Object type: user
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;proxyAddresses;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchUCVoiceMailSettings;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchUserHoldPolicies;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchArchiveStatus;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchSafeSendersHash;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchBlockedSendersHash;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchSafeRecipientsHash;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msDS-ExternalDirectoryObjectID;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;publicDelegates;user'"
Invoke-Expression $cmd | Out-Null

#Object type: iNetOrgPerson
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;proxyAddresses;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchUCVoiceMailSettings;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchUserHoldPolicies;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchArchiveStatus;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchSafeSendersHash;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchBlockedSendersHash;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchSafeRecipientsHash;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msDS-ExternalDirectoryObjectID;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;publicDelegates;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null

#Object type: group
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;proxyAddresses;group'"
Invoke-Expression $cmd | Out-Null

#Object type: contact
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;proxyAddresses;contact'"
Invoke-Expression $cmd | Out-Null

Finally you need to run the above once per domain.

Preparing for User Writeback

[This functionality is not in the current builds of AADConnect]

Currently in preview at the time of writing, you are able to make users in Azure Active Directory (cloud users as Office 365 would call them) and write them back to on-premises Active Directory. The users password is not written back and so needs changing before the user can login on-premises.

To prepare the on-premises Active Directory to writeback user objects you need to run this script. This is contained in AdSyncPrep.psm1 and that is installed as part of Azure AD Connect. Azure AD Connect will install Azure AD Sync, which is needed to do the writeback. To load the AdSyncPrep.psm1 module into PowerShell run Import-Module ‘C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1’ from an administrative PowerShell session.

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is an account usually in the form of AAD_number].
$cloudUserOU = "OU=CloudUsers,DC=contoso,DC=com"
Initialize-ADSyncUserWriteBack -AdConnectorAccount $accountName -UserWriteBackContainerDN $cloudUserOU

Once the next AADSync occurs you should see users in the OU used above that match the cloud users in Office 365 as shown:

image

Prepare for Windows 10 Registered Device Writeback Sync

Windows 10 devices that are joined to your domain can be written to Azure Active Directory as a registered device, and so conditional access rules on device ownership can be enforced. To do this you need to import the AdSyncPrep.psm1 module. This module supports the following two additional cmdlets to prepare your Active Directory for Windows 10 device sync:

CD "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep"
Import-Module .\AdSyncPrep.psm1
Initialize-ADSyncDomainJoinedComputerSync
Initialize-ADSyncNGCKeysWriteBack

These cmdlets are run as follows:

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is an account usually in the form of AAD_number].
$azureAdCreds = Get-Credential #[Azure Active Directory administrator account]

CD "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep"
Import-Module .\AdSyncPrep.psm1
Initialize-ADSyncDomainJoinedComputerSync -AdConnectorAccount $accountName -AzureADCredentials $azureAdCreds 
Initialize-ADSyncNGCKeysWriteBack -AdConnectorAccount $accountName 

Once complete, open Active Directory Sites and Services and from the View menu Show Services Node. Then you should see the GUID of your domain under the Device Registration Configuration container.

image