When trying to deploy a Windows 7 image from WDS I was confronted by the above error. The error occurred whilst trying to deploy different Windows 7 images to different computers and laptops.

After routing through log files and the internet I was starting to get a little frustrated. At this point I thought that I would try using the install.wim that comes on the Windows 7 CD to see what happens. Whilst browsing the \sources folder on the CD I noticed the boot.wim file. Now, although I have never needed to add multiple boot.wim files for the assorted OS’ I already deploy off this WDS Server I thought I would add the boot.wim (right-click Boot Image in WDS and select ‘Add Boot Image’. I labelled the new boot.wim file to ‘Windows 7 Deploy’ on import and then chose this option when PXE booting the Laptop.

Hey presto, it now works without any errors.

Hopefully this will save someone the headache I received getting to this point.

Good luck

Neil

I recently hit a problem with CWA being published behind TMG, CWA was accessible internally from a terminal server but would throw the above error when login was attempted via TMG’s reverse proxy. 

The solution (for me – there is a fair bit written about this involving SPNs which were not the issue in this case), was to enable anonymous authentication on the AuthMainCommandHandler.ashx file (within the /cwa directory) within IIS & all is well again, it is reported that this issue only occurs on Server 2008 & is an issue with the site creation wizard.

My colleague Simon also hit this issue publishing CWA behind UAG, so worth checking.

Richard Hicks has a great blog entry on this at http://tmgblog.richardhicks.com/2010/03/20/migrating-from-isa-to-tmg/ so I won’t go into detail on the overall process. However, there are a couple of gotchas to be aware of, although these aren’t anything to do with TMG itself.

First, as you are probably moving from Server 2003 to Server 2008, the number of trusted commercial Certificate Authorities has been trimmed down – if you are importing an SSL certificate from one of the less well known authorities,  the root CA may not be trusted. The import will succeed, TMG will allow you to specify the cert in publishing rules, but the results can then be unpredictable. Note that if you do have to add the root CA to your trusted CA store after TMG has been configured to use the SSL certificate, it is worth rebooting the server – without a reboot, TMG registers no errors, but client devices may display untrusted cert errors.

Therefore, when you import SSL certificates onto the TMG server, verify three things:

• The certificate is in the local machine’s Personal store
• 
• The certificate has a matching private key
• 
• The certificate path is fully validated
• 

Second, if you are planning a TMG to ISA migration, you will probably be moving to new hardware, as it will have to be a side by side migration. This obviously means that the MAC addresses of all your NIC’s are going to change, so talk to your networking guys – at the very least, you will probably need ARP tables on the relevant routers/switches to be flushed at the point you actually swap cables, otherwise you  may end up with the situation I was in, where TMG was up and running with no errors, but no traffic for publishing rules on addresses other than the native IP address of the external NIC ever hit TMG, which was definitely a head scratcher for a while .

HTH