locked
Install Enterprise CA option is greyed out RRS feed

  • Question

  • I'm having issues with the "enterprise CA" option being grayed out during installation of the ADCS role for a 2008 R1 Enterprise Edition server (for a new Ent. Sub. CA).  The account I was using had Enterprise Admin rights in the root domain and Domain Admin rights for the child domain that the CA will be installed into (I don't need root domain admin since I have enterprise admin, right?).  The server is already joined to the domain.  I verified Enterprise Admins have full control for Public Key Policy container and all child containers.  I have not tried to re-create this as another CA (2003) is online within the same domain/forest - I would prefer not having to do this if at all possible.  I tried moving the capolicy.inf out of windir in case it was getting in the way.  I believe I have the firewall cleaned up - is there an official resource that documents how to configure the firewall for just the CA?  I'm not installing web services or anything else - this is a dedicated box.

    Thanks in advance...

    Monday, January 24, 2011 10:52 PM

Answers

  • On Tue, 25 Jan 2011 21:21:24 +0000, Steve        F wrote:

    I already pulled myself back out of the enterprise & schema admin groups.

    You must be a member of either Enterprise Admins or Domain Admins in the
    forest root domain in order to install an Enterprise CA.


    Paul Adare
    MVP - Identity Lifecycle Manager
    http://www.identit.ca
    That does not compute.

    • Marked as answer by Bruce-Liu Friday, February 4, 2011 6:53 AM
    Tuesday, January 25, 2011 9:28 PM
  • This is not a change in permissions issue.

    The OCM log file is stating that it cannot determine if you are a member of the enterprise admins group.

    That is the problem that you need to solve.

    Brian

    • Marked as answer by Bruce-Liu Friday, February 4, 2011 6:53 AM
    Wednesday, January 26, 2011 6:27 PM
  • The devil was in the details... I omitted entering the WINS server settings, so the child domain was not able to see the rest of the directory.  I got the Enterprise dot now.

    Thanks for all the help folks!

    • Marked as answer by Steve F Thursday, January 27, 2011 8:00 PM
    Thursday, January 27, 2011 8:00 PM

All replies

  • Check out the c:\windows\certocm.log file. It will give you details on what went wrong when it tried to enumerate your membership in the Enterprise Admins group.

    For an enterprise CA, your account only needs to be a member of the Enterprise Admins group and a member of the local Administrators group. Due to the Universal group status of Enterprise Admins, I typically try and use a root domain account that is a member of the local Administrators group on the local server (rather than a child domain account added to Enterprise Admins

    Brian

    Monday, January 24, 2011 10:58 PM
  • Hi,

     

    Besides the above suggestions, this article might be helpful:

     

    http://support.microsoft.com//kb/938613

     

    The containers are same in Windows Server 2008.

     

    Hope this helps.


    This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Tuesday, January 25, 2011 6:18 AM
  • Keep getting ENUM_ENTERPRISE_UNAVAIL_REASON_NO_INSTALL_RIGHTS

    I did some asking around - it sounds like they took the enterprise admins out of the schema admins group.  I've never really seen it documented to need schema admin rights - which makes sense I suppose. 

    Thanks for the help, guys!

    • Marked as answer by Steve F Tuesday, January 25, 2011 3:23 PM
    • Unmarked as answer by Steve F Tuesday, January 25, 2011 3:57 PM
    • Marked as answer by Steve F Tuesday, January 25, 2011 4:05 PM
    • Unmarked as answer by Steve F Tuesday, January 25, 2011 7:16 PM
    Tuesday, January 25, 2011 3:23 PM
  • OK, so I just tried with Enterprise Admin, Schema Admin, and Local Admin  rights.  Still grayed out. (yes, I logged out/back in after getting additional rights).  I'm still curious if I really need Schema Admin or not, particularly since we're stifling the templates in the capolicy.inf.  Our AD forest is 2003 for both parent and child, I'm unsure of the schema version but can find out if anyone cares.

    Enterprise CA option availability status: ENUM_ENTERPRISE_UNAVAIL_REASON_NO_INSTALL_RIGHTS

    Google gives me nothing on that one.  Wow.

    Side note: the previous PKI was set up by a previous team with a number of customizations - I'm not sure just how typical some of these are for a very large enterprise.  For example we have a separate OU for CA servers, I have put the box into that already.  I guess I'm saying assume nothing about the environment, it is very customized and I cannot describe how it may or may not be special.

    Any ideas?  Thanks again!


    Tuesday, January 25, 2011 7:30 PM
  • On Tue, 25 Jan 2011 19:30:36 +0000, Steve        F wrote:

    OK, so I just tried with Enterprise Admin, Schema Admin, and Local Admin? rights.? Still grayed out. (yes, I logged out/back in after getting additional rights).? I'm still curious if I really need Schema Admin or not, particularly since we're stifling the templates in the capolicy.inf.? Our AD forest is 2003 for both parent and child, I'm unsure of the schema version but can find out if anyone cares.

    Enterprise CA option availability status: ENUM_ENTERPRISE_UNAVAIL_REASON_NO_INSTALL_RIGHTS

    Can you run whoami /groups with the currently logged in account and then
    post the results?


    Paul Adare
    MVP - Identity Lifecycle Manager
    http://www.identit.ca
    A CONS is an object which cares.  -- Bernie Greenberg

    Tuesday, January 25, 2011 8:01 PM
  • Thanks, Paul.

    I already pulled myself back out of the enterprise & schema admin groups.  Here's what I have left - if its necessary I can check again when I'm part of those groups again.  There are a couple extra cert related groups I added myself to at the end here trying to troubleshoot stuff, probably not necessary but they shouldn't hurt anything.  I'm leaving out a few groups that should have nothing to do with this to avoid clutter.

    Everyone

    BUILTIN\Users

    BUILTIN\Administrators

    BUILTIN\Certificate Service DCOM Access

    BUILTIN\Distributed COM Users

    NT AUTHORITY\INTERACTIVE

    NT AUTHORITY\Authenticated Users

    NT AUTHORITY\This Organization

    LOCAL

    CHILD_DOMAIN\Domain Admins

    CHILD_DOMAIN\(Our CA Team group)

    CHILD_DOMAIN\GPA_REPOSITORY_MANAGEMENT

     

    All groups are listed as enabled, if run from an elevated cmd box.

    I tried rebooting a few times.

    Tried logging in as child_domain\username and username@child.domain.test

    I turned on the software firewall logging and all logged traffic is allowed.

    Ran through the various event logs and nothing is jumping out at me.

     

     

    Tuesday, January 25, 2011 9:21 PM
  • On Tue, 25 Jan 2011 21:21:24 +0000, Steve        F wrote:

    I already pulled myself back out of the enterprise & schema admin groups.

    You must be a member of either Enterprise Admins or Domain Admins in the
    forest root domain in order to install an Enterprise CA.


    Paul Adare
    MVP - Identity Lifecycle Manager
    http://www.identit.ca
    That does not compute.

    • Marked as answer by Bruce-Liu Friday, February 4, 2011 6:53 AM
    Tuesday, January 25, 2011 9:28 PM
  • Per Brian's earlier request, here's more from the certocm.log

     

    114.679.948: Begin: CCertSrvSetup::InitializeDefaults
    109.7852.0: 0x80070002 (WIN32: 2)
    109.7871.0: 0x80070002 (WIN32: 2)
    109.7852.0: 0x80070002 (WIN32: 2)
    401.1285.946: Opened Policy inf: C:\Windows\CAPolicy.inf
    454.244.0: 0x80004005 (-2147467259): AES-GMAC
    454.244.0: 0x80004005 (-2147467259): SHA224
    429.2157.0: 0x51 (WIN32: 81)
    429.2157.0: 0x51 (WIN32: 81)
    812.426.0: 0x8007003a (WIN32: 58)
    429.466.0: 0x8007003a (WIN32: 58)
    429.2390.0: 0x8007003a (WIN32: 58)
    109.883.1838: Enterprise CA option availability status: ENUM_ENTERPRISE_UNAVAIL_REASON_NO_INSTALL_RIGHTS
    109.1072.0: 0xe0000102 (INF: -536870654)
    114.732.0: 0xe0000102 (INF: -536870654)
    454.334.0: 0x80004005 (-2147467259)
    454.334.0: 0x80004005 (-2147467259)
    454.334.0: 0x80004005 (-2147467259)
    454.244.0: 0x80004005 (-2147467259): AES-GMAC
    454.244.0: 0x80004005 (-2147467259): SHA224
    454.244.0: 0x80004005 (-2147467259): AES-GMAC
    454.244.0: 0x80004005 (-2147467259): SHA224
    454.244.0: 0x80004005 (-2147467259): AES-GMAC
    454.244.0: 0x80004005 (-2147467259): SHA224
    454.244.0: 0x80004005 (-2147467259): AES-GMAC
    454.244.0: 0x80004005 (-2147467259): SHA224
    454.244.0: 0x80004005 (-2147467259): AES-GMAC
    454.244.0: 0x80004005 (-2147467259): SHA224
    454.244.0: 0x80004005 (-2147467259): AES-GMAC
    454.244.0: 0x80004005 (-2147467259): SHA224
    454.244.0: 0x80004005 (-2147467259): AES-GMAC
    454.244.0: 0x80004005 (-2147467259): SHA224
    454.244.0: 0x80004005 (-2147467259): AES-GMAC
    454.244.0: 0x80004005 (-2147467259): SHA224
    454.244.0: 0x80004005 (-2147467259): AES-GMAC
    454.244.0: 0x80004005 (-2147467259): SHA224
    454.244.0: 0x80004005 (-2147467259): AES-GMAC
    454.244.0: 0x80004005 (-2147467259): SHA224
    454.244.0: 0x80004005 (-2147467259): AES-GMAC
    454.244.0: 0x80004005 (-2147467259): SHA224
    420.110.0: 0x80090014 (-2146893804): Microsoft Software Key Storage Provider
    420.117.0: 0x80090014 (-2146893804): child_domain-HOSTNAME-CA
    114.878.949: End: CCertSrvSetup::InitializeDefaults
    114.4612.948: Begin: CCertSrvSetup::GetExistingCACertificates
    114.4766.949: End: CCertSrvSetup::GetExistingCACertificates
    114.3414.948: Begin: CCertSrvSetup::GetProviderNameList
    114.3491.949: End: CCertSrvSetup::GetProviderNameList
    114.3286.948: Begin: CCertSrvSetup::GetSupportedCATypes
    114.3346.949: End: CCertSrvSetup::GetSupportedCATypes
    114.3987.948: Begin: CCertSrvSetup::GetPrivateKeyContainerList
    114.4098.949: End: CCertSrvSetup::GetPrivateKeyContainerList
    114.4612.948: Begin: CCertSrvSetup::GetExistingCACertificates
    114.4766.949: End: CCertSrvSetup::GetExistingCACertificates
    114.3987.948: Begin: CCertSrvSetup::GetPrivateKeyContainerList
    114.4098.949: End: CCertSrvSetup::GetPrivateKeyContainerList
    114.3748.948: Begin: CCertSrvSetup::GetKeyLengthList
    114.3796.949: End: CCertSrvSetup::GetKeyLengthList
    114.3822.948: Begin: CCertSrvSetup::GetHashAlgorithmList
    114.3963.949: End: CCertSrvSetup::GetHashAlgorithmList
    114.3822.948: Begin: CCertSrvSetup::GetHashAlgorithmList
    114.3963.949: End: CCertSrvSetup::GetHashAlgorithmList

    Tuesday, January 25, 2011 9:31 PM
  • One of our guys was picking up on:  -2147467259 and -536870654.

    Not sure what he was looking at, but seems to be under the impression that it could be related to registry entries that dont' exist and cannot be created for some reason, or having to do with the server writing to registries or maybe to the sysvol? he was referencing 2008 R2, but we are running R1 - if that matters at all I don't know.  For all I know this could be a total red herring or it could be right on target - any opinions?

    Thanks again for all your help

     

    Also (I can make a new thread for this if needed), does anyone happen to have a list of what schema changes do actually occur with a 2008 R1 Enterprise Sub. CA going into a 2003 AD?  I know that v3 templates won't be available, etc. - I'm looking for what, if anything, does actually pop up.  If there is a delta between 2008 R1 & 2003 R1 that would be awesome.

    I came across this that pointed to that the schema is actually updated in order to support v3 templates:

    http://www.corelan.be:8800/index.php/2008/07/14/windows-2008-pki-certificate-authority-ad-cs-basics/

    I have LoadDefaultTemplates=0 in the capolicy.inf & it is a 2003 AD, so either way it shouldn't get updated anyways.  However, for down the road I would like to know what specific schema changes are actually applied during this process.

     

    Tuesday, January 25, 2011 9:46 PM
  • No schema updates are applied during the installation.

    In fact, you will get V3 certificate templates even with the 2003 schema

    What you will not get are permissions for Read Only Domain Controllers on the KDC templates (Kerberos Auth, Domain Controller Auth, Directory Email Replication, and Domain Controllers). You also cannot install services such as HTTP-based enrollment, as these require the schema updates.

    Schema updates are performed by loading the LDF files only. Not by enabling ADCS.

    I think you may have replication issues with the DCs or something else not catching the enumeration.

    As Paul stated, your whoami dump does not include Enterprise Admins.

    Can you please try the installation with an account from the forest root domain that is a member of:

    - ForestRoot\Enterprise Admins

    - CAComputer\Administrators

    Thanks

    Brian

    Tuesday, January 25, 2011 9:58 PM
  • Sorry, Paul & Brian - I think you misunderstood me.  I removed myself from those groups *after* attempting the problematic install.  I'm not normally a member of Enterprise/Schema admins groups, it was just bestowed up on me temporarily (yes I logged out/back in afterwards and confirmed the group membership). By the time I could do the whoami dump for you I was already out and didn't want to request that kind of access for that kind of query unless there's some kind of nesting that you're wondering about, which I can check manually. However I was in the correct groups at install time as I attempted to note previously.  When I next attempt the install I will be requesting access once again.

    Brian - much thanks for breaking down where the schema updates occur during the installation.  I will try to dig up the LDF files to determine what is going on with web enrollment when it comes time to install that box.  Right now I'm just doing the CA and nothing else.

     

     

     

    Tuesday, January 25, 2011 10:55 PM
  • So I guess the next question is: what does the Enterprise Admin need rights to, that may have potentially been removed? I have checked Public Key Services and the subfolders in ADSS.  I have not taken a granular look at any of the contents, which I don't think there is a need to.

    Is there a way to enable more verbose logging that could result in better details in the logs?

    Wednesday, January 26, 2011 3:39 PM
  • This is not a change in permissions issue.

    The OCM log file is stating that it cannot determine if you are a member of the enterprise admins group.

    That is the problem that you need to solve.

    Brian

    • Marked as answer by Bruce-Liu Friday, February 4, 2011 6:53 AM
    Wednesday, January 26, 2011 6:27 PM
  • The devil was in the details... I omitted entering the WINS server settings, so the child domain was not able to see the rest of the directory.  I got the Enterprise dot now.

    Thanks for all the help folks!

    • Marked as answer by Steve F Thursday, January 27, 2011 8:00 PM
    Thursday, January 27, 2011 8:00 PM
  • Um Steve,

    Please mark the answerers posts as answered, not your own.

    Brian

    Thursday, January 27, 2011 8:41 PM
  • This is what worked for me.

    I had a user object created , had it assigned as a member of domain admin and enterprise admin groups .

    Logged in to the server on which CA's have to be installed and installed it successfully.

    This did not work for me and i received the same error.

    Used administrator account (domain) which is a member of domain admin and enterprise admin to install the CA

    • Proposed as answer by Moonshekar Friday, July 13, 2012 10:45 AM
    Sunday, March 25, 2012 11:16 AM
  • So, do we get a proper reason for this or different people are facing the same issue because of different reasons??

    Thanks

    Regards

    Wednesday, August 20, 2014 11:57 AM
  • 2 different issues, it looks like to me:

    Steve F found he "omitted entering the WINS server settings, so the child domain was not able to see the rest of the directory."  I'm not sure what WINS settings have to do with installing a CA and it knowing he was an Enterprise Admin.  I don't know why WINS is even necessary, if you have updated servers (Windows Server 2000+) all on the same network using DNS and it is replicating correctly.  I guess they opted for WINS, instead?  But if a server he's working on couldn't connect to AD and find he was an Enterprise Admin because WINS was not set up/accessible and couldn't relay his server to AD, perhaps that could cause it?  (Grasping at straws...)  But then he wouldn't be able to authenticate into the server (unless he had done so, before the connection to WINS/AD was disconnected).

    Moonshekar "Used administrator account (domain) which is a member of domain admin and enterprise admin to install the CA".  This should be the real answer, if there are not extenuating circumstances like Steve F.'s.


    Thursday, April 27, 2017 8:48 PM
  • I am experiencing this issue - Enterprise CA greyed out.  I researched this issue thoroughly and cannot find a solution.  I am posting here as a last resort with the hope someone can suggest a solution.

    Ultimately, I am trying to create a VPN server.  In route to achieving that goal, I need to install AD CS.  When I attempt to configure AD CS and when I need to specify Enterprise CA or Standalone CA, the Enterprise CA option is greyed out.

    I attempted to install AD CS on a Windows Server 2016 server.

    I am using my own user account versus the domain administrator's account.  I am a member of the Domain Admins and Enterprise Admins groups.  See group information below:


    C:\Windows\system32>whoami /groups

    GROUP INFORMATION
    -----------------

    Group Name                                 Type             
    ========================================== ================ 
    Everyone                                   Well-known group 
    BUILTIN\Administrators                     Alias            
    BUILTIN\Users                              Alias            
    NT AUTHORITY\REMOTE INTERACTIVE LOGON      Well-known group 
    NT AUTHORITY\INTERACTIVE                   Well-known group 
    NT AUTHORITY\Authenticated Users           Well-known group 
    NT AUTHORITY\This Organization             Well-known group 
    LOCAL                                      Well-known group
    JDC\WseRemoteAccessUsers                   Group            
    JDC\Group Policy Creator Owners            Group            
    JDC\WseAllowHomePageLinks                  Group            
    JDC\WseAllowMediaAccess                    Group            
    JDC\WseAllowComputerAccess                 Group            
    JDC\WseAlertAdministrators                 Group            
    JDC\WseAllowShareAccess                    Group            
    JDC\Domain Admins                          Group            
    JDC\WseInvisibleToDashboard                Group            
    JDC\WseAllowDashboardAccess                Group            
    JDC\WseAllowAddInAccess                    Group            
    JDC\WseRemoteWebAccessUsers                Group            
    JDC\Enterprise Admins                      Group            
    JDC\Schema Admins                          Group            
    Authentication authority asserted identity Well-known group 
    JDC\Denied RODC Password Replication Group Alias            
    Mandatory Label\High Mandatory Level       Label 

    The server is a member of the domain.  It communicates successfully with the domain controllers.  See nslookup and nltest below:


    C:\Windows\system32>nslookup jdc.local
    Server:  DC.JDC.local
    Address:  192.168.0.2

    Name:    jdc.local
    Addresses:  192.168.0.43
              192.168.0.2
              192.168.0.33

    C:\Windows\system32>nltest /dsgetdc:jdc.local
               DC: \\DC.JDC.local
          Address: \\192.168.0.2
         Dom Guid: 4d418deb-26ae-4a00-806f-e44bf066c524
         Dom Name: JDC.local
      Forest Name: JDC.local
     Dc Site Name: Default-First-Site-Name
    Our Site Name: Default-First-Site-Name
            Flags: PDC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE FULL_SECRET WS DS_8 DS_9

    I reviewed the CA log.  It indicates an account's rights issue with my account - 109.883.1838: <2018/8/4, 17:14:05>: Enterprise CA option availability status: ENUM_ENTERPRISE_UNAVAIL_REASON_NO_INSTALL_RIGHTS

    I tried all of the above with the domain administrator's account as well - same result.

    I feel like I've exhausted all options save for posting here.  Any assistance or suggestions will be greatly appreciated.


    John Criswell

    Sunday, August 5, 2018 1:26 PM
  • I am experiencing this issue - Enterprise CA greyed out.  I researched this issue thoroughly and cannot find a solution.  I am posting here as a last resort with the hope someone can suggest a solution.

    Ultimately, I am trying to create a VPN server.  In route to achieving that goal, I need to install AD CS.  When I attempt to configure AD CS and when I need to specify Enterprise CA or Standalone CA, the Enterprise CA option is greyed out.

    I attempted to install AD CS on a Windows Server 2016 server.

    I am using my own user account versus the domain administrator's account.  I am a member of the Domain Admins and Enterprise Admins groups.  See group information below:

    I reviewed the CA log.  It indicates an account's rights issue with my account - 109.883.1838: <2018/8/4, 17:14:05>: Enterprise CA option availability status: ENUM_ENTERPRISE_UNAVAIL_REASON_NO_INSTALL_RIGHTS

    I tried all of the above with the domain administrator's account as well - same result.

    I feel like I've exhausted all options save for posting here.  Any assistance or suggestions will be greatly appreciated.


    John Criswell

    Making some progress.  Reviewed Active Directory for Sites and Services.  Noticed two previously created CAs.  I have a little home network consisting of two stand alone servers running Hyper-V and some virtual machines hosted on the two servers.  One of the virtual machines is the target of my attempt to install a VPN and AD CS.  When I saw the two CAs, I realized they were created when I installed AnywhereAccess on these machines. This was done about a year ago. They are running Windows Server Essentials 2012 R2.  Surely, this is the reason Enterprise CA option is greyed out when configuring  AD CS.  I googled and found a good article on how to clean ones server of a certification authority - https://support.microsoft.com/en-us/help/889250/how-to-decommission-a-windows-enterprise-certification-authority-and-r.  I am in the process of removing the certification authorities from these servers.  Will report back on my progress and success or failure with the "Enterprise CA option greyed out" issue. 


    John Criswell

    Update --

    Removed all traces of Certificate Authority and Certificate Services from the servers mentioned above.  No luck.  Tried to install and configure AD CS on other member servers in the domain.  When the configuration wizard was run, Enterprise CA was still greyed out.  

    I am currently at a loss.

    • Edited by jdccons Wednesday, August 8, 2018 11:47 AM
    Monday, August 6, 2018 5:10 PM
  • I also had the EnterpriseCA option greyed out after migrating from a standalone CA to an Enterprise until I changed the following registry key:

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\CertSvc\Configuration\CA1]

    "UseDS"=dword:00000001

    Sunday, September 30, 2018 11:23 AM
  • I also had this problem after reinstalling the CA. The solution was to open Active Directory Sites and Services in the DC and removing the entries related to the previous CA manually. This post helped me: https://nolabnoparty.com/en/remove-ca-active-directory/.

    Hope it's useful for somebody reading this.



    Sunday, May 26, 2019 1:19 AM
  • Hello,

    After Spending a few hours on this issue, reading and trying almost every suggestion in this article that didnt help, I figure that the problem was a communication error. some for the firewalls ActiveDirectory predefine services (ip/ports) are configured with partial ActiveDirectory ports. this cause the enumeration of the error ENUM_ENTERPRISE_UNAVAIL_REASON_NO_INSTALL_RIGHTS to be raised since the server cant find required in formation on the domain controller due to communication error. 

    I opened the firewall (Fortigate) to be Any in the service field and all works fine!
    If it helps you, please mark this answer to help others. 

    Itzik Sharon


    Tuesday, June 18, 2019 1:55 PM
  • Since Windows 2008, an EnterpriseCA can only be installed on a domain member but no longer on a domain controller.  Enterprise CA option is greyed out / unavailable if that's the case.


    Alex


    Alexander Ollischer Diplom-Wirtschaftsinformatiker (FH) Citrix & Microsoft Certified Engineer (CCEA, CCEE, MCSA, MCSE, MCDBA, MCTS) Afontis IT+Services GmbH Baierbrunner Straße 15 81379 München Deutschland Telefon (089) 74 34 55-0 Fax (089) 74 34 55-55 mailto:a.ollischer@afontis.de http://www.afontis.de http://www.itganzeinfach.de Amtsgericht München, HRB 109 005 Geschäftsführer: Thomas Klimmer

    Wednesday, July 10, 2019 1:43 PM
  • Since Windows 2008, an EnterpriseCA can only be installed on a domain member but no longer on a domain controller.  Enterprise CA option is greyed out / unavailable if that's the case.



    That is simply not true. An enterprise CA always had to installed on a domain member, all the way back to Windows 2000 and there is absolutely nothing preventing you from creating an enterprise CA on a domain controller. This screen shot shows that on a 2016 domain controller.
    Wednesday, July 10, 2019 8:14 PM