Exhange 2007 Active Sync intermittent credential prompts with TMG

This is a real world issue I had.  Publishing Exchange through ISA 2006 was fairly easy.  I had a single rule that I used to publish outlook Web Access and Active Sync.  After moving over to TMG 2010 we started getting a rather annoying problem.

Windows Mobile phones would intermittently request the users credentials when attempting to sync.  This despite "save password" being checked.  Also if you just "left it" the phone would sync perfectly
a few minutes later.

It took a while to figure out but what happens is that the authentication cookie on the phone does not expire when the ip changes.  When this happens the authentication cookies is no longer valid and the user is prompted again.

So to fix this Microsoft recommended publishing Active Sync with a separate rule.  Using the same listener, same settings etc.  The only difference is that the path.  This then solved the issue.

According to MS this is why:

Our guidelines would be to create a separate rule because there are some
internal TMG setting which allow a Client Agent like MSFT-SPhone/5.2.5080 which
doesn’t support HTML Form authentication to fall back to basic auth. This should
be transparent for the user and shouldn’t be prompted to authenticate.

Change the default certificate used by RDS

When building an RDS environment you will at some point add more RD Session host servers.  At this point you will start running into certificate issues because the requested name does not match the certificate anymore.

You might also be prompted that the certificates is form an untrusted source.  This is because by default the RDS server will use a self signed certificate.

In a proper RDS environment you will most probably be using a SAN certificate that is exported and installed on  all the RDSH servers.

To change the the certificate being used you need to do the following:

• Get the certificate thumbprint.
• Copy the thumbprint into notepad and remove all the spaces

Copy the following script and save it as rdconfig.js

var strComputer = ".";

var strNamespace = "\\root\\CIMV2\\TerminalServices";

var wbemChangeFlagUpdateOnly = 1;

var wbemAuthenticationLevelPktPrivacy = 6;


var Locator = new ActiveXObject("WbemScripting.SWbemLocator");


Locator.Security_.AuthenticationLevel = wbemAuthenticationLevelPktPrivacy;


var Service = Locator.ConnectServer (strComputer, strNamespace);

var TSSettings = Service.Get("Win32_TSGeneralSetting.TerminalName=\"RDP-Tcp\"");


if (WScript.Arguments.length >= 1 )

{

    TSSettings.SSLCertificateSHA1Hash = WScript.Arguments(0);

}

else

{

     TSSettings.SSLCertificateSHA1Hash = "0000000000000000000000000000000000000000";

}


TSSettings.Put_(wbemChangeFlagUpdateOnly);

Open a command prompt and execute the script specifying the edited thumbprint as the parameter

cscript rdconfig.js 0e2a9eb75f1afc321790407fa4b130e0e4e223e2

This will now set the default certificate to be used by the RDS

If at any point you want to revert back to using the self signed certificate just execute the script without specifying a parameter.

 

Customise RDS Web access login pages

I again went through the process of publishing RDS.  This time i thought i would "skin it" in my corporate colors.

The files that need to be edited are located in the following directory of the Web Access Server

 C:\Windows\Web\RDWeb\

The images are located in C:\Windows\Web\RDWeb\Pages\images
This is how they correspond to the page layout.

The style sheet is in C:\Windows\Web\RDWeb\Pages\en-US

Annoyingly not all the page elements colors are catered for in the style sheets, so you will also have to edit:

login.aspx
desktop.aspx
default.aspx
config.aspx

While you are going through these files you will aslo see a section called  // Localizable Text
This section contains all the string values used throughout the page.  So if you want to change the text of any of the filed this would be the place to do it.



To change the title of the page you need to go to the connection broker machine, open up Remote Desktop Connection Manager.  Under the Properties section change the "Display name"

So with just a few edits we now have a corporate look and feel as well as some branding in there too.

Sophos Software Update Manager reading the log

The Sophos SUM has got many improvements over the old EM Library.  One of the only problems I still have with it is that it is hard to figure out what it is doing and what is going on.

This is especially true when you have a new installation and you are doing the initial software download, the enterprise console tell you Downloading Binaries, but how do you know if it is actually "going"

There is a log viewer.  For some reason it is not easily accessible. The logviewer.exe is located in the following directory

C:\Program Files (x86)\Sophos\Enterprise Console\SUM\Logviewer.exe

At the top of the log viewer there are two filters.  The first one "in red" is the severity filter.  This is handy to only display errors.
The filter options are:

• All
• Success
• Information
• Warning
• Error

The second Filter sets the logging level - or level of detail.  Importantly this does not change the log itself, just the display of the log. The filter option are

• Verbose
• Normal
• Important

To check that your download is actually happening all you have to do is change the logging level form normal to verbose.  This will then give you far more detail, and hitting the refresh button you can see the activity (auto refresh would be nice Sophos.)

This is currently displaying all the individual files being downloaded to the Warehouse.

If you want to know more about the size of the individual files you can browse to the folder directly and see how they are coming in and how big they are.  The folder is:

C:\ProgramData\Sophos\Update Manager\Update Manager\Warehouse

You can now correlate the items for the log viewer to actual files on the machine.

Once the warehouse is update with all the files it needs, depending on the Software Subscription, the files will then be compiled into the CID.  This is what can then be used to protect the client machines.

C:\ProgramData\Sophos\Update Manager\Update Manager\CIDs

By the time everything has finished the status in the Enterprise console will change from "Downloading Binaries to "Last checked at:"

Troubleshooting Sophos Message Relay issues

In a previous article I described how to set up Message Relay machines to improve the scalability of a single Sophos Management server.  See http://fixmyitsystem.blogspot.com/2010/11/configure-sophos-message-relay-for.html

I was quite happy that I got everything working properly, so I figured let me build my production environment. This is where things got a little ugly.  I got stuck not being able to get my clients to use the message router.

What to look for in the communications report:

the Sophos Management server should look like this

A Client machine communicating directly with the management server looks like this.  Note the parent address refers to the Management server

The message router should look like this.  Note the RMS router type has to say message router

A client machine using the message relay looks like this. Note the name of the parent address refers to the message relay

When a machine updates and changes message relay you should see the following during the update.

Only this one file is retrieved and then it is followed by the reinstall of the RMS component.  If you do not see this file coming in and there is no install then nothing has changed.


Remember to check and refresh the Communications report


While checking these on the various machine I noticed the following issues.

Message relay machine remains as an endpoint RMS

After step 3 of http://fixmyitsystem.blogspot.com/2010/11/configure-sophos-message-relay-for.html your message relay should show up as a message relay in the Connection report.  Mine faild to do this even though it worked during the lab.  I found the problem....eventually.

You also need to copy your edited mrinit.conf file into the SAVSCFXP root.  If you reinstall the message relay from here it will now correctly configure the machine as the message relay.

Client machines do not start using the message relay even though they are updating from the MR machine

In theory and according to Sophos documentation.  If you point a client machine to a CID that has been configured to act as a MR the machine should update itself an start using the MR.  You can confirm this by checking the connection report.

 
There is one big catch here though.  The edited mrinit.conf file's "created on" date needs to be different to the one it was installed with.  It appears that the only way the client knows to get the new mrinit.conf file is by the date.  If they are different it will happily detect the alternate file, download and install it.  If the dates are the same it won’t download or install.