Creating a Site to Site VPN using the ISA 2006 Firewall Branch Office Connection Wizard (Part 7)

If you missed the other parts in this article series, check them out at:

If you would like to be notified of when Tom Shinder releases the next part in this article series please sign up to our Real Time Article Update newsletter.

Branch Office Domain Controller Scenario

Thanks for coming back for more of my series on creating a site to site VPN network using the ISA Firewall. Last week we created Enterprise Policies that will allow us to put up a domain controller in the branch office. Last week’s article was a special event for us on, since it was the first time ever in a public forum that there was a discussion and examples of how to use and create Enterprise Policies that enable you to push firewall configuration automatically to a worldwide deployment of ISA Firewall arrays. If you missed that article, check it out now!

Discuss this article

At this point we have the site to site VPN working smoothly and we’re ready to deploy the branch office domain controller. Once we get the branch office domain controller online, we can install an Active Directory integrated DNS server on that DC and configure the branch office ISA Firewall to use that DNS server as its primary DNS server. This helps break the dependence on the site to site VPN connection for DNS service availability.

In this week’s article we’ll look at some of the effects RPC communications have through the ISA Firewall. This article is a little different, in that we’ll have more questions left unanswered than answered. However, I hope that by bringing these issues to the light of day, we will be able to harness the collective knowledge and experience of the ISA Firewall community to come up with answers to some of these questions.

Disable Strict RPC Compliance on the Intradomain Communications Rule

A common problem seen when communications take place through the ISA Firewall is that autoenrollment does not work correctly. Another problem that appears to be closely related to that one is that the Certificates MMC snap-in doesn’t work. There is a KB article indicating that if we disable strict RPC compliance on our Access Rule, then the RPC communications required for autoenrollment and the Certificates MMC will work. I have to tell you, in my experience, I’ve never seen this work. However, I have heard from other people that they actually have seen this work. Because of this, we’ll give it a try in our lab environment and see what happens.

We want certificate autoenrollment to work because we have an enterprise CA installed on the main office domain controller. Because we have a enterprise CA in place, this allows us to have the CA certificate of the enterprise CA automatically placed in the Trusted Root Certificate Authorities machine certificate store of all domain members. This is a great convenience, since it allows all our domain members to automatically trust the certificates issued by our enterprise PKI.

Perform the following steps to disable strict RPC compliance on our intradomain communications Access Rule:

  1. In the ISA Firewall console, expand the Enterprise node and then expand the Enterprise Policies node. Click the Branch Policy node. Right click the Branch DCs > Main DC Access Rule and click Configure RPC protocol.

Figure 1

  1. In the Configure RPC protocol policy dialog box, remove the checkmark from the Enforce strict RPC compliance checkbox. Click OK.

Figure 2

  1. Click Apply to save the changes and update the firewall policy. Click OK in the Apply New Configuration dialog box.

Some people have asked me whether we should re-enable strict RPC compliance after we install the branch office DC. I don’t have a definitive answer for this, as the exact details of what this setting does are not publicly available. I think it’s safe to assume that it’s more secure to have strict RPC compliance enabled, but if this security feature breaks core functionality, and since the security benefits have not been articulated anywhere in a public forum, then our best choice is to disable this feature and obtain the functionality benefits.

However, the final decision is up to you. If you don’t need autoenrollment to work (and we haven’t demonstrated yet for sure whether autoenrollment will work when this feature is disabled) then you might want to leave strict RPC compliance in place.

Bottom line is that there is no hard and fast right or wrong answer here, which is the case for most security related decisions.

Run DCPromo on the Branch Office Domain Controller Machine

Now we’re ready to install the domain controller at the branch office. How you accomplish this task depends on your environment. Many companies that I’ve worked with will create a lab environment with an IP addressing scheme that mirrors the branch office deployment and install and configure the DC at the main office before shipping it to the branch office. Other companies that I’ve worked with will ship the DC machine to the branch office and then have main office IT personnel visit the branch office to setup the DC.

There are advantages and disadvantages to each option. I personally prefer to send an IT pro to the branch office, since DC deployment is critical and it’s often best to have someone on site who can troubleshoot potential problems.

Perform the following steps to install the DC on the branch office domain controller machine:

  1. Click Start, click Run and enter dcpromo in the Open text box. Click OK.
  2. Click Next on the Welcome to the Active Directory Installation Wizard page.
  3. Read the information on the Operating System Compatibility page and click Next.
  4. On the Domain Controller Type page, select the Additional domain controller for an existing domain option and click Next.

Figure 3

  1. On the Network Credentials page, enter the credentials of a user who has permission to install new domain controllers and click Next.

Figure 4

  1. On the Additional Domain Controller page, click the Browse button and click the name of the main office domain. In this example, the name of the domain is, so we’ll select that domain from the list in the Browse for Domain dialog box. Click OK and then click Next.

Figure 5

  1. On the Database and Log Folders page, accept the defaults and click Next.
  2. On the Shared System Volume page, accept the default location and click Next.
  3. Enter a password and confirm the password on the Directory Services Restore Mode Administrator Password page and click Next.
  4. Click Next on the Summary page and click Next.
  5. The installation wizard starts. Let it continue until you see the completion page.

Figure 6

  1. Click Finish on the Completing the Active Directory Installation Wizard page.

Figure 7

  1. Click the Restart Now button in the Active Directory Installation Wizard dialog box.

The Dcpromo process worked flawlessly! There were no errors during installation and the machine rebooted and everything appeared to work OK. If you open up the Certificates MMC you’ll see that the enterprise CA certificate is automatically populated in the Trusted Root Certification Authorities certificate store, just as we wanted, as seen I the figure below.

Figure 8

However, if we open the Event Viewer, we’ll see some errors that may indicate some real problems. The figure below shows that autoenrollment didn’t work and the branch office DC did not receive a DC certificate. Is this a real error? Is this a real problem? Is this a problem related to the ISA Firewall?

Discuss this article

Figure 9

The figure below shows another error that might be significant. This error indicates that the branch office domain controller cannot query for a list of group policy objects. This sounds like a big problem. Is it? Is it a problem with the ISA Firewall? Is it an indication of another problem?

Figure 10

The figure below shows an error indicating that DCOM was unable to communicate with the domain controller at the main office ( Is this a problem with the ISA Firewall? Something else?

Figure 11

But are these errors actually true? Perhaps they were generated at a point in time during startup before the site to site VPN was activated? I considered this, but I confirmed that the site to site VPN was up and functional during system startup for the branch office DC.

Are we sure that autoenrollment doesn’t work? We saw that the CA certificate was automatically populated in the Trusted Root Certification Authorities certificate store. Should there be a DC certificate automatically assigned? Or do we need to create a policy for this to happen?

As for group policy processing, is it actually true that group policy isn’t being processed?

To test this, make a small change to Domain Group Policy at the main office domain controller. For example, go to the Desktop node in the Administrative Templates section in the User Configuration section, as seen in the figure below.

Figure 12

Next, double click the Remove Recycle Bin icon from desktop entry in the right pane and click the Enable section. Click OK and then run the gpupdate /force command at the main office domain controller. After that completes, run the gpupdate /force command at the branch office. What happens?

Figure 13

From my testing and experience, group policy is applied at both the main and branch offices, and the recycle bin object is removed from the desktop (you might have to refresh the desktop to see this change). So, we’ve learned the lesson, once again, that we can’t always trust what we see in the Event Viewer.

How about the Certificates MMC? Unfortunately, the Certificates MMC doesn’t work, in spite of the comments made in the KB article at However, perhaps I haven’t completely configured the ISA Firewalls to meet the specifications in that KB article. Here are the salient instructions from that KB article:

“To request a certificate for the ISA Server computer, click to clear the Enforce strict RPC compliance check box in the System Policy Editor dialog box. However, to request a certificate for a client computer when the client computer and the Certification Authority are on different networks, you do not have to modify the system policy on the ISA Server computer. In this scenario, you must modify the strict RPC-compliance settings for the rule or rules that permit traffic between the two networks. To do this, follow these steps:

  1. Start the ISA Server Management tool.
  2. Expand the ServerName node, and then click Firewall Policy.
  3. Right-click the rule that permits traffic between the network where the Certification Authority resides and the network where the client computer resides.
  4. Click Configure RPC Protocol.
  5. Click to clear the Enforce strict RPC compliance check box, and then click OK.
  6. Repeat steps 3 through 5 to modify system policy rules and to permit DCOM communications between any other rules that are between two particular networks.
  7. When you have finished modifying policy rules, click Apply

Notice step 6, which is something I find really interesting. How would system policy be involved with any other rules that are between two particular networks? What does this mean? Does it mean System Policy rules that apply to communications between two ISA Firewall Networks? How can this be? System Policy only controls traffic that either sources from the ISA Firewall or is directed to the ISA Firewall. How then could a System Policy Rule control traffic between two networks.

Perhaps this is some sort of secret hint that is being delivered to us from the ISA sustained engineering group? In order to test this hypothesis, let’s see what happens if we disabled strict RPC compliance at the System Policy level. The only way to do this is to open the System Policy editor at the array level.

Click on the Firewall Policy in the left pane of the ISA Firewall console and then click on the Tasks tab in the Task Pane. In the Task Pane, click the Edit System Policy link. Click on the Authentication Services policy group in the left pane and then remove the checkmark from the Enforce strict RPC compliance checkbox. Click OK. Perform this action on both the ISA Firewalls.

Figure 14

In order to test this, I restarted both the ISA Firewalls to make sure that the RPC state table entries were removed. I don’t know if that’s required, but it’s the most reliable way to confirm that the tables are cleared. I also restarted the branch office domain controller. The result? The Certificates MMC failed to connect to the enterprise CA. You will see the error below:

Figure 15

Both of the reasons mentioned in the error are incorrect. The CA was online and I was logged on as an enterprise administrator. A look at the branch office ISA Firewall’s real time log viewer shows us some hints that the RPC filter is the problem:

Figure 16

These log file entries were taken when the certificate request was sent from the branch office domain controller to the main office DC, which is also an enterprise CA. The only conclusion we can come to, at least in my studies, is that the recommendations in the KB article at are incorrect, or there is some vagary in my lab environment, using VMware workstation, that prevents this from working correctly. If you have got this to work correctly, please write to me at [email protected] and let me know.

What are my conclusions? First, do what is recommended in the KB article. Microsoft would not publish this article unless they have strong evidence that the configurations they describe actually work. Second, Group Policy processing seems to work fine, so you don’t need to worry about that. Third, I’m still not sure if autoenrollment isn’t working, as I haven’t set up an autoenrollment policy in Group Policy and I’m not sure if domain controllers are automatically assigned machine certificates (OK, this is my bad – I should know this but haven’t been able to find information on this issue yet).

Discuss this article


In this article we spent some time examining what happens when we install a DC at the branch office. Unfortunately, there are more questions than answers at this point. Microsoft documentation states that all of our troubles should be solved by disabling strict RPC compliance, but we continue to see a number of RPC related communications errors in the Event Viewer. Can we believe what we see in the Event Viewer? It suggests that Group Policy processing doesn’t work, but we can see that Group Policies are applied. What about autoenrollment? Perhaps we need to create a policy first. And then there is the Certificates MMC issue.

We have more questions than answers at this time, but can say that for the most part, our domain controller seems to be working properly. Next week we’ll configure an Active Directory site for the branch office and configure the site link. We’ll also create a DNS server on the branch office DC and change the DNS settings on the ISA Firewall. See you then! – Tom.

If you missed the other parts in this article series, check them out at:

If you would like to be notified of when Tom Shinder releases the next part in this article series please sign up to our Real Time Article Update newsletter.

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top