Firewall settings could not be configured?

When you try to activate UAG, you might find yourself staring at an error saying “firewall settings could not be configured, unknown error 0xc00403c4”

This is not a very common situation, but it may happen if you have made changes or additions to the firewall rules on TMG that’s on the UAG server. As you may or may not know, making changes to the TMG configuration on a UAG server is not only unsupported (except some specific scenarios), but also dangerous. Normally, UAG is in charge of being the configuration king, and when you perform a configuration activation, it pushes certain settings into the TMG configuration. Interfering with this process is hazardous, and can lead to disappointments such as the one above, or even worse. How? Well, the TMG is there to serve as a security layer for your protection, and making changes or additions to the rules may cause a conflict that could lead to inoperability of the server, or a security exposure. The above example is exactly this kind of thing. When you make such manual changes to the TMG configuration, it may prevent it from accepting the settings that UAG tries to create, and can leave you with a server that is completely unresponsive to client requests.

If you do run into the error above, start by making sure no one made any changes to the configuration, and if some were made, reverse them. In some circumstances, such a chance may work for a while, and show its ugly head much later, when you create a new trunk or make some other significant configuration change.

If you are wondering what specific scenarios I was referring to earlier, these are documented here: https://technet.microsoft.com/en-us/library/ee522953.aspx. Additionally, if working on a support case, a Microsoft representative may guide you to make manual changes, which is perfectly fine, of course.

One scenario for which we have seen users make changes to their Config is when trying to provide access to or from external servers. For example, to allow themselves to RDP into the UAG server from a corporate machine, such a change would be required. However, there’s a proper and supported way to do this:

1. Open the TMG console, and go to Firewall Policy

2. On the Toolbox tab, click Network Objects.

3. Expand Computer Sets, and then double-click Remote Management Computers:

4. On the Remote Management Computers Properties dialog box, click Add, and then select Computer.

5. On the New Computer Rule Element dialog box, type the name of the computer, in Computer IP Address, enter the IP address of the remote computer, and then in the Description box, provide an optional description. On the New Computer Rule Element dialog box, click OK:

6. On the Remote Management Computers Properties dialog box, click OK.

7. On the Apply Changes bar, click the Apply button, and then on the Saving Configuration Changes dialog box, click OK.

Another scenario which we have seen is when the UAG computer needs to run some software that needs to connect to some backend server. For example, an Anti Virus or backup agent. This is not as simple as it looks, as the UAG supportability guidelines also dictate that no additional software should be installed on the UAG server, to prevent potential conflict with the UAG or TMG software. This mostly applies to service software, while Microsoft is more forgiving towards protection software like an Anti Virus. There are several other considerations for using AntiVirus software on a UAG server, and these are discussed here: https://technet.microsoft.com/en-us/library/cc707727.aspx. However, the point here is that if a certain piece of software requires access to some other computer, the right way to do it is not by manually creating a TMG rule. Instead, create an app!

The idea here is to configure a “ghost” application that will make UAG configure TMG to allow the traffic we need. The application will not be used by anyone, and we can even make it hidden. All it will do is specify servers and ports that UAG needs to push into TMG. Here’s how:

1. On the UAG portal, create a new application. If you have more than one trunk, it can be done on any of them – it does not matter.

2. Select “Client/Server and legacy” group, select “Generic Client Application”. You may also select “Generic Client Application(Multiple Servers)” if you need to add multiple servers, or multiple ports.

3. Give the application a descriptive name to remind yourself what it is for

4. Choose any access policy – it doesn’t matter, as it won’t be used by users anyway.

5. In step 4 of the wizard, specify the IP or name of the servers that need to be accessible:

6. On step 5 of the wizard, uncheck the option to show the app on the portal:

7. Finish the wizard, and activate the configuration.

As part of the activation process, UAG will create an access rule to allow access to the server(s) and port(s) specified in step 4, and your problem should be over!

Props to Thomas for working this with me!