Microsoft Forefront Threat Management Gateway - traps for young players pt. i

While rolling out a TMG infrastructure recently, I have come across a bunch of issues. I’ll be making some documentation of them below, as I haven’t found much on Google that seemed to indicate the issues I have been having.


Issue #1 – Wrong certificate on Web Listener

At the start of the project I wanted to stage all my publishing rules on the reverse proxy TMG, so I created everything with all the right settings, except for the SSL certificate that would be used in production. No problem, I thought, I’ll use the built in TMG server cert until I get the real ones, and just swap them out in the Listener properties.


This was not straightforward. I loaded the correct UC cert and changed the properties of the listener to use this cert for the defined IP address - it all looked good in the TMG console, but when I browsed to the published OWA site, I found that it was using the TMG server certificate. The only way I could fix was to delete the publishing rule and associated listener. And then export the UC cert with key - reimported, recreated everything and it worked.


Issue #2 - WA - LDAPS authentication not working, only non-secure LDAP on Workgroup TMG


I installed the Enterprise CA cert on the workgroup member TMG server, this allowed TMG to trust DC for LDAPS.


Issue #3 Reinstalling TMG fails on Reporting Services

I had to reinstall two TMGs as we had to change network template from single NIC to Back Firewall. I uninstalled everything, but could not reinstall.

I had to uninstall SQL client, manually delete all SQL folders under Program File folders and uninstall ADLDS
After this TMG reinstalled just fine.

Issue # 4 Published CRM issues 

CRM published through TMG was not working at all to start with – this was caused by the bridging of https 443 traffic to http 5555 – the firewall saw the 5555 traffic as unidentified traffic and denied it.

This turned out because I had “Enable Forefront TMG Client support for this network” disabled (Networking -> Networks -> Internal Properties -> Forefront TMG Client)

Once this was working, I found that CRM was popping up a Windows Authentication box, instead of the CRM Forms logon.

This was because the "Internal Network" in the IFD configuration is blank on the CRM server, so the CRM Server thinks our connections in via the TMG are from internally, therefore it is expecting Kerberos authentication to be used rather than forms authentication.

Still, the connection was bad, sometimes I would get “Internet Explorer cannot display the webpage”, and when I was logged on it would time out rather quickly.

What I found to help was to disable HTTP Compression, the compression filter and the caching filter.

CRM is still a little bit niggly, but a lot better :)


Issue #5 TMG HTTPS Inspection blocks Skype

When using TMG as the forward proxy, HTTPS inspection kills Skype. I have found no answer for why on the internets, but my theory is that it is not the inspection of the traffic itself, but that when this rule is enabled, TMG must verify the certificates at the destination and because these maybe self signed then it will simply not initiate the connection. This would explain why you can’t set a source exemption for this rule and have it work

I am sure there will be more to come in another post.

To change network interfaces on XenDesktop machine catalogs

When you are adding a new XenDesktop host to your XenDesktop 5 deployment, you will select the guest network that all created desktops will have as thier default.

As with most configuration in XenDesktop 5, changing what this network is after the initial setup requires PowerShell and some manual intervention

For existing virtual desktops, reconfigure the network interfaces manually through the vCenter console – i.e. right click the desktops and edit settings, change network label.

To ensure that all future desktops are then created with the correct interface the default has to be changed using PowerShell
First, open a PowerShell console as administrator.

Load the Citrix cmdlets:
Add-PSSnapin "Citrix*"

Discover the network path:
get-item xdhyp:\hostingunits\<hostname>

Where ‘hostname’ is what the virtual infrastructure is named as in the XenDesktop Desktop Studio console. (In the main view select Configuration -> Hosts -> and look for the server name for the vCenter server or XenServer resource pool)

Type this command:
get-item xdhyp:\hostingunits\<hostname>

The results should be returned, and one line will be:
NetworkPath          : XDHyp:\Connections\Melbourne\ESX.datacenter\Lab.cluster\OLD.network

Use the information to change the network path as required:
set-item xdhyp:\hostingunits\<hostname> -networkpath XDHyp:\Connections\Melbourne\ESX.datacenter\Lab.cluster\NEW.network

New Network Path will be the network interface name as it appears in vCenter console, appended with “.network”.
After this is complete, any new XenDesktop virtual machines created using MCS will have the new network interface assigned automatically.

XenApp Connector for System Center Configuration Manager (SCCM) 2007 R2 – PT I.

A quick overview of the Connector

The newish Connector for XenApp/Config Manager is great. I like the automation of installing applications out of hours, although I haven’t used the publishing aspect of it yet, just the deployment tool.

http://www.citrix.com/English/ps2/products/subfeature.asp?contentID=2301676

At a high level, the Connector is the integration point for XenApp 6 and SCCM 2007 R2. With the Connector you can advertise applications to XenApp and let the Connector handle draining the server, notifying the users of impending installs and logging them off. Once the application is installed, the Connector can publish the applications and also push users back on to the server.

The Connector uses the Citrix Power and Capacity Manager to handle the draining of servers,which is done by changing the logon preference from 1^st Choice to whatever the lowest choice is.

Installation is pretty straight forward, but there are some tweaks you can make to the Connector to get it working just the way you want. 

With the XenApp Connector, application advertisements run a task sequence

When an advertisement is run the following actions happen:

1.    Citrix Power and Capacity Management changes the connection preference for servers targeted in the Collection and that haven’t processed the advertisement to drain user connections.

2.    Then the task sequence will run on the targeted server, if there are user sessions then the advert will fail. The Advertisement Wait timeout starts counting from the first time the server processes any mandatory assignment

3.    If a previous mandatory assignment has failed, and there are still user sessions, and the Advertisement Wait period has passed, then the following will happen:

              i.        Users will be warned of impending logoff, and asked to save their work

             ii.        Users will be logged off after the time set expires

            iii.        Server logons will be disabled

            iv.        The application will install

             v.        Logons will be enabled on the server

            vi.        Logon preference will be set back to normal

Change Advertisement wait times

When installing the Connector console extension, the default settings for the Advert Wait time is three days, and it is not possible to set it to less than one day but more than 0 through the GUI. To do this, the following file must be changed on any machines the console extension is installed on.

Browse to

C:\Program Files\Citrix\XenApp Connector for ConfigMgr 2007\
Edit the XASCCM.config file in notepad
The file should look like this:

<XASCCMConfig version="1.00">

  <XADistributionPackage>

    <ForceDateInterval>0.00:10:00</ForceDateInterval>

    <ForceOutWarningNotification>

      <LastMinuteInterval>00:05:00</LastMinuteInterval>

      <MessageTitle>Upcoming Maintenance</MessageTitle>

      <MessageBody>Please save your work and logoff, server will be in maintenance mode in 5 minutes.</MessageBody>

    </ForceOutWarningNotification>

  </XADistributionPackage>
</XASCCMConfig>

XenDesktop Machine Creation Service

So, I’ve just finished building a XenDesktop 5 proof of concept for a client:

XenServer 5.6 FP1

Provisioning Server 5.6 SP1

XenDesktop 5

Windows 7

All was going well and everything was setup, I had the golden image ready. So I go to start deploying the desktops when I discovered there is no XenDesktop Wizard! Doh!

Just my luck XenDesktop 5 now has its own deployment wizard, the Machine Creation Service (MCS). It is totally sweet, you just do the following in the Desktop Studio:

Hook your XenDesktop controller up to the hosting XenServer

Start the MCS wizard

Select how many desktops, select your primary VM, naming, AD membership.

Next, next finish – you have a bunch of virtual desktops!

Not sure if this feature will unseat PVS, but it is definitely the go for POC’s and small implementations.

Nice one Citrix J