Domain Controller Demotion Error: The operations master roles held by this directory server could not transfer to the following remote directory server.

In demoting a Domain Controller, ran into the following error:

The operations master roles held by this directory server could not transfer to the following remote directory server. 

FSMO Role: CN=Infrastructure,DC=ForestDnsZones,DC=domain,DC=local

Apparently during the last demotion, the roles for the DNS Zones weren't transferred (both for Forest and Domain). There is an easy fix, but it wasn't very straight forward to google.

1. On the new Domain Controller (the one you're not demoting), open notepad and paste this into a file named fixfsmo.vbs:
   
   

   const ADS_NAME_INITTYPE_GC = 3
   const ADS_NAME_TYPE_1779 = 1
   const ADS_NAME_TYPE_CANONICAL = 2
   
   set inArgs = WScript.Arguments
   
   if (inArgs.Count = 1) then
       ' Assume the command line argument is the NDNC (in DN form) to use.
       NdncDN = inArgs(0)
   Else
       Wscript.StdOut.Write "usage: cscript fixfsmo.vbs NdncDN"
   End if
   
   if (NdncDN <> "") then
   
       ' Convert the DN form of the NDNC into DNS dotted form.
       Set objTranslator = CreateObject("NameTranslate")
       objTranslator.Init ADS_NAME_INITTYPE_GC, ""
       objTranslator.Set ADS_NAME_TYPE_1779, NdncDN
       strDomainDNS = objTranslator.Get(ADS_NAME_TYPE_CANONICAL)
       strDomainDNS = Left(strDomainDNS, len(strDomainDNS)-1)
       
       Wscript.Echo "DNS name: " & strDomainDNS
   
       ' Find a domain controller that hosts this NDNC and that is online.
       set objRootDSE = GetObject("LDAP://" & strDomainDNS & "/RootDSE")
       strDnsHostName = objRootDSE.Get("dnsHostName")
       strDsServiceName = objRootDSE.Get("dsServiceName")
       Wscript.Echo "Using DC " & strDnsHostName
   
       ' Get the current infrastructure fsmo.
       strInfraDN = "CN=Infrastructure," & NdncDN
       set objInfra = GetObject("LDAP://" & strInfraDN)
       Wscript.Echo "infra fsmo is " & objInfra.fsmoroleowner
   
       ' If the current fsmo holder is deleted, set the fsmo holder to this domain controller.
   
       if (InStr(objInfra.fsmoroleowner, "\0ADEL:") > 0) then
   
           ' Set the fsmo holder to this domain controller.
           objInfra.Put "fSMORoleOwner",  strDsServiceName
           objInfra.SetInfo
   
           ' Read the fsmo holder back.
           set objInfra = GetObject("LDAP://" & strInfraDN)
           Wscript.Echo "infra fsmo changed to:" & objInfra.fsmoroleowner
   
       End if
   
   End if
   

2. Open an administrator cmd prompt at the location of the vbs
3. Run it once each with ForestDnsZones and DomainDnsZones (or just specify the one you're getting in the error) like this:
   
   

   cscript fixfsmo.vbs DC=ForestDnsZones,DC=domain,DC=local

4. You will need to fully close and re-run dcpromo to do the demotion, but it should go through now

Credit to this blog for the script.

Setting up ConnectWise Manage with Duo Access Gateway via SAML

This will give you all the details on how to set up ConnectWise Manage with Duo Access Gateway via SAML. I could not find any documentation for the pairing of these two products, so there was a little bit of trial and error.

Pre-Requisites

• A Duo Access Gateway (DAG) server already setup and ready to go.
• A Duo account with Duo MFA or higher licensing. (the free version does not support this)
• You must have an admin account to both CW:M and Duo (duh)

Recommendations/Caveats

• The moment you save the SSO configuration in CW:M, it will remove all settings related to LDAP and existing 2FA with Google Authenticator. The CW documentation says it disables it, but no, it rips it out.
• I recommend you sync your training database and do the setup there first. This way you can do it live, and also avoid issues caused by the point above
• I am not going to train you on how to use the various products, this is just about the integration. I expect you already know how to create applications in Duo and add them to the access gateway.
• This example is going to be for the training database in CW:M, so all URLs etc will reference that. The fake CW:M URL i will be using is manage.domain.com, and your DAG URL will be dag.company.com

Duo Setup

1. Log into the Duo Admin Panel and create a new Application of type SAML - Service Provider
2. Enter the following settings:
   
   • Service Provider Name: ConnectWise Manage - Training
   • Entity ID: https://manage.company.com/v4_6_release/auth/training/metadata
   • Assertion Consumer Service: https://manage.company.com/v4_6_release/auth/training/Acs
   • Service Provider Login URL: https://manage.company.com
   • NameID Format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
   • NameID attribute: userPrincipalName (this can also be mail, just make sure it's an email address format that your DAG is pulling in from your identity source
   • All other settings: default
3. Click Save Configuration
4. Scroll down and set the name of the Application (i recommend setting it to the same thing: ConnectWise Manage - Training)
5. Save and then click the link at the top to download the configuration file
6. Head over to your DAG admin panel and upload the downloaded json file
7. Download the certificate

CW:M Setup

1. Navigate to System > Authentication (or Setup Tables > SSO Configuration)
2. Set the following options:
   • Description: Duo Access Gateway (this can be whatever you want)
   • SSO Type: SAML
   • Login URL: copy and paste SSO URL from the DAG Admin
   • Identity Provider ID: copy and paste Entity ID from the DAG Admin
   • Identity Provider Certificate: upload the certificate you downloaded from the DAG Admin
   • Locations: check the box for the locations that this SSO applies to. In most cases it will just be All.
3. Save and you're ready to test
4. Use a different (incognito/private) browser window to test so you don't get locked out.
5. Upon login it will redirect you to the SSO login. It will also handle user enrollments here so if this is a brand new org it's a good way to force your users to enroll
6. Once you're done and tested, repeat the process for your production database. Replace training in the URLs with your company id. Create a new Duo Application for this, that way you will have it always working in both live and training.

Chrome, Remote Desktop Services, and Time Zone Redirection

If you're using RDS and have enabled the GPO for Time Zone Redirection, there is a small issue with Chrome that may cause some issues. For whatever reason, JavaScript date functions in Chrome will pull the system's time data instead of the user's. So if your server is in UTC and your user is in Eastern, Chrome's detection will come back as UTC. Firefox and Internet Explorer do not appear to have this flaw (i did not test with Edge).

To tell if you're affected, open the Chrome inspector (Ctrl+Shift+I) and go to the Console tab. If you just enter in new Date() you will see a preview of what the date is, including the time zone.

As far as i can tell, there is no workaround, if someone has one please let me know. I'll be setting up separate pools for users just for this.