ADCS Server 2012 R2 Auto Enrollment with hardening - RPC Server Unavailable

On a Windows 2012 R2 server with the ADCS role installed you get an error "RPC server unavailable" after trying to request a certificate from a published template.



The first thing to look for is access rights.

In all the posts on the internet I came across mentioned to check whether the Authenticated users group had acces on several objects. The idea is in the right direction but not quite the solution yet.

In Windows Server 2012 R2 in combination with a hardening policy you need to use the Domain Users group as well.

So check for the Authenticated Users group and add the Domain Users group in the following places:The local server group: Certificate DCOM Access






The properties of the CA server itself, Authenticated Users, Domain Computers, Domain Controllers and Domain Users should be present.

On the CA server itself the Certsrv directory in C;\Windows\System32\ should have Read and Execute rights for Authenticated users and Domain Users.

In Active Directory\Builtin locate the "Users" group and check for Authenticated Users and Domain Users

Check the DCOM Access Limit of “My Computer” of the DC:

1- On the server, run dcomcnfg.exe.

2- On the Component Services console, navigate to Component Services\Computers\My Computer.

3- Right-click My Computer, select Properties, verify that Enable Distributed COM on this computer is selected in the Default Properties tab. 

4- Click the COM Security tab, Click Edit Limits in the Access Permission section and ensure that Everyone and Certificate Service DCOM Access has Local Access and Remote Access permissions.

5- Click Edit Limits in the Launch and Activation Permission section and ensure that Certificate Service DCOM Access group has Local Activation and Remote Activation permissions.

6- Click OK.

This should be enough to get those certificates rolling again.

Best Practice for RPC Timeouts in Exchange

Exchange 2010 and 2007 use RPC (Remote Procedure Calls) for all client and RPC proxy calls. For example, email clients (Outlook, Outlook Anywhere (OA), and ActiveSync) use RPC for MAPI connectivity.

The default keep alive time for RPC connections uses the IIS idle connection timeout, which is 15 minutes. This usually doesn't cause a problem on local LAN or WAN connections, but routers and switches that are used to connect Internet clients to internal Exchange servers often have more aggressive timeouts. Typically these network devices have a 5 minute timeout which causes problems for external clients, particularly Outlook Anywhere, iPhone, and iPad clients. Symptoms include messages stuck in the Outbox and poor email performance on the remote clients, and high CPU utilization on the Exchange Client Access Servers (CAS).

The new best practice is to adjust the RPC keep alive timeout value on the Client Access Server from 15 minutes to 2 minutes. Since RPC is a function of Windows, not Exchange, this value is adjusted under the Windows NT registry key. The value is located here:

HKLM\Software\Policies\Microsoft\Windows NT\RPC\MinimumConnectionTimeout

Normally the MinimumConnectionTimeout DWORD value does not exist, which means RPC uses the default value of 900 seconds (15 minutes). To adjust it, create or modify the MinimumConnectionTimeout value and set the value to decimal 120 (seconds, or 2 minutes). IIS must be restarted on the CAS to affect the change.

The following command will create the appropriate values:

reg add "HKLM\Software\Policies\Microsoft\Windows NT\RPC" -v "MinimumConnectionTimeout" -t REG_DWORD -d 120

The Outlook and ActiveSync clients honor this new timeout during the connection to the CAS, so both client and server now send a Keep-Alive packet after two minutes of inactivity, effectively maintaining both TCP connections needed.

A colleague of mine works for a large global company that was affected by this. They have several thousand iPads connecting to nine load balanced CAS servers and all the CAS were peaking at 100% CPU utilization. Once they implemented this change the average load on the CAS is now 20-30% and the iPad performance is much improved.

This is my new best practice and I make this change on every Exchange CAS deployment. For more information about RPC over HTTP see Configuring Computers for RPC over HTTP on TechNet.

Source

Outlook Anywhere RPC over HTTP

Symptoms:

Attempting to ping RPC endpoint 6001 (Exchange Information Store) on server server.contoso.com.
The attempt to ping the endpoint failed.
Additional Details An RPC error was thrown by the RPC Runtime process.
Error 1818 CallCancelled

Source

On the Mailbox servers: a DWORD entry needs to be created on each Mailbox server named "Do Not Refer HTTP to DSProxy" at HKLM\System\CCS\Services\MSExchangeSA\Parameters\ and the value set to "1".
Next, as indicated earlier, the RPCProxy will block access to the DC servers unless there servers are included in the ValidPorts regkey.
So, set the following on the Client Access Servers:
1.The ValidPorts setting at HKLM\Software\Microsoft\RPC\RPCProxy needs setting so that the entries referring to 6004 point to DC servers in addition to the mailbox server.
2.The PeriodicPollingMinutes key at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeServiceHost\RpcHttpConfigurator\ needs setting to zero to prevent RpcHttpConfigurator from updating the Valid Ports key automatically.
Finally, you need to make sure that the DCs are listening on port 6004:
On the Global Catalog servers: a REG_MULTI_SZ entry needs to be created on each GC named NSPI interface protocol sequences at HKLM\System\CCS\Services\NTDS\Parameters\ and the value set to ncacn_http:6004.
There is 1 last thing to deal with in this SSL-ID load balanced configuration.
Outlook profile creation hard codes a call to DSProxy on 6004.
Which means that we can get split connectivity during profile creation.
To deal with this minimal volume of traffic, there is 1 final regkey that should be set on the mailbox servers:
On the Mailbox Servers - set the HKLM\System\CCS\Services\MSExchangeSA \Parameters key "NSPI Target Server" to the FQDN of the DC that profile creation should use.
By using only 1 DC for profile creation, all DSProxy calls will be proxied into that single DC, once again avoiding split connectivity.

Source