Thursday, 29 July 2010

Important Update to the ‘How to Configure ISA SSL Bridging for System Center Configuration Manager Internet-Based Client Management’ Documentation!

There is a lot of talk about the remote management capabilities of DirectAccess and there is no doubt that this is the future of Microsoft’s remote access strategy. However, for environments that are not running Windows 7 Enterprise/Ultimate client systems or who need to manage non-corporate (read non-domain joined) clients, then the DirectAccess solution may not be possible or appropriate. Other factors may also prevent the use of DirectAccess for some reason I can’t think of right now!

In these scenarios, it is possible to use technology provided by the System Center Configuration Manager (ConfigMgr) product and a feature called Internet-Based Client Management (IBCM). This feature allows external clients to securely connect to ConfigMgr in order to manage them as if they were connected to the LAN (doesn’t that sound familiar!). You can find more details on IBCM here. This is not quite the full capability provided by DirectAccess connectivity, but is still very worthy of consideration…

Some of the updates are a direct result of my feedback to Microsoft on real-world usage of the solution, especially when customers are running internal deployments of Windows Server 2003 Certificate Services or Windows Server 2008 Active Directory Certificate Services (AD CS) and a feature called Autoenrolment. It is great to see the document evolve and also provide customers with a realistic solution that is fully supported and tested by Microsoft. I have greatly enjoyed working with the folks involved (you know who you are!) and feel that the time invested is very worthwhile…

The updated article can be found here or you can read more about the specific document updates in the ConfigMgr Team Blog.

Wednesday, 21 July 2010

What Happens When a Forefront TMG Array Manager Fails?

Forefront TMG Enterprise Edition introduced the concept of a new array called the Standalone Array. This technology is based upon the old locally installed Configuration Storage Server (CSS) model and does not require the use of a dedicated management server. Unlike the existing model, there is now the concept of an Array Manager server and other array members are termed Array Managed servers. Only one array manager can exist within an array and this essentially becomes the master configuration owner.

A common question to ask (as people did with ISA Server 2006 EE and the CSS role) is What happens when the array manager fails or is offline for some other reason?

With the array manager offline:

  • The remaining Forefront TMG array managed servers will continue to operate and provide full firewall functionality using a locally cached version of the Forefront TMG configuration/policy.
  • The remaining Forefront TMG array managed servers will not enter Lockdown Mode due to the lack of an array manager as should operate normally.
  • You will not be able to access the Forefront TMG configuration or connect to it using the Forefront TMG Management console. Consequently you cannot make changes to the firewall policy or monitor the Forefront TMG environment, amongst other administrative tasks provided by the console.

When the array manager comes back online:

  • The remaining Forefront TMG array members will synchronise with the array manager to obtain updated local cache configuration.
  • You will be able to access the Forefront TMG configuration and connect to it using the Forefront TMG Management console from the array manager or the array managed servers.

When the array manager cannot come back online, or is going to be offline for a long period of time, it is probably unacceptable to lose access to the Forefront TMG configuration or be unable to connect to it using the Forefront TMG Management console. In this scenario, the recommended option is to designate an existing, fully functional array managed server as the new array manager. This is achieved using the Set as Array Manager link from Tasks tab of the Forefront TMG Management console.

This process is documented here and appears to be a simple task. However, this document does not cover the expectation of the administrator when it comes to actually performing the procedure on the following counts:

  • In reality, the process involves some considerable time delays where it is easy to think that the process has stalled or hung.
  • It does not cater for the fact that you may be using a workgroup deployment which requires the administrator to assign SSL server certificates to the array manager as part of the process.
  • The array name remains unchanged and will show the computer name of the existing array manager, not the current array manager computer name.
  • What happens if you start the existing array manager once you have designated a new array manager, or you want to bring the array manager back online as an array member.

So, I thought it would be useful to document this process with a real-world slant with a basic walkthrough…

The example environment I will use is the same as that used for my Workgroup Deployment with Forefront TMG Enterprise Edition series of articles, namely:

image

Where TMG03 is the array manager server and TMG04 is the array managed server. As this environment is based upon a standalone array for a workgroup deployment, this also allows us to see the additional steps required for this scenario (which is handy).

So, assuming that TMG03 has failed or is taken offline, we will need to designate TMG04 as the new array manager as shown below.

Starting the Forefront TMG Management console on TMG04 you will notice that you receive the following error as the existing array manager (TMG03) is not operational:

2010-07-15_1147

After clicking Continue it will take a long time for the console to load. From my testing this could take up to 3 or 4 minutes before the console is accessible. For many people, this is an unexpectedly long delay and it would be common place to assume the process has stalled or hung. However, please be patient!

2010-07-15_1148

 2010-07-15_1153

Once the console has loaded, there should be an option under the Tasks tab for Set as Array Manager as shown below:

 2010-07-15_1152

If you are using a workgroup deployment (as per our example environment) you will see the following prompt:

2010-07-15_1154

In order to designate this server as the new array manager, you will need to have created an SSL server certificate that can be used for workgroup authentication. In our case, the certificate will need a common name of TMG04.dmz.com as discussed in previous workgroup articles. The above prompt assumes that this certificate is available in an exported PFX file format with an associated password. Once you have selected the appropriate PFX file and entered the correct password, the Setting this server as the array manager… process will begin:

2010-07-15_1154_001 

Please Note: If you receive an error that the ISASTGCTRL service cannot be started, it may be necessary to reconfigure this service to use a startup type of Automatic as opposed to the default startup type of Disabled.

Once completed, you should now see the the console connected to the local Forefront TMG configuration storage server which contains all previous configuration and settings; TMG04 is now the new array manager:

2010-07-15_1335

2010-07-15_1336_001 

A quick look around the console should confirm that TMG04 is now the array manager and the Forefront TMG configuration is synchronised:

2010-07-15_1337

2010-07-15_1409

2010-07-15_1335_001

If you have an array with more than two array members, it will now be necessary to configure remaining array members to use the new array manager with the Change Array Manager option available on the Tasks tab of the Forefront TMG Management console.


Once you have designated TMG04 as the array manager, in the event that TMG03 is brought back online it will no longer be able to participate in the array and Forefront TMG will need to uninstalled, reinstalled and then rejoined to the array now managed by TMG04. It will also be necessary to delete the existing TMG03 server object from the Servers tab of the System node (on TMG04) before attempting to join the array and also remove the TMG03 entry from the Managed Server Computers computer set (on TMG04).

Hope this helps!