RD Web Access + RD Gateway + Multiple ISPs

Congratulations, you've successfully implemented a RD Web Access + RD Gateway solution.  Perhaps  you're trying to emulate Remote Web Workplace or Citrix XenApp.  The accolades of your peers continued until that day when the primary internet line went down for 8 hours.  Suddenly you've become the guy who implemented a business critical solution with a single point of failure in Baby Bell.

The problem, while RD Web Access (TS Web Access in the non-R2 version of 2008) will give you a warning about non-matching certificate which you can ignore, RD Gateway (TS Gateway in non-R2) simply fails.  Changing DNS records to point to the secondary isp could take hours, and manually programming the DNS entry in every client's computer would likely take just as long (not to mention prevent you from failing back).

Microsoft doesn't seem to provide any obvious answer for this situation.  However, the need for a certificate to work from multiple urls is not new.  Star certs and UCC certs provide exactly this functionality.  Furthermore there are millions of IIS and Apache servers out there which have successfully implemented multi-tenanted solutions which require the ability to determine which url the end user requested to provide the correct webpage.

The first step is go acquire a UCC or Star cert for the domain.  Since it's still one site in IIS, it can't handle providing a different certificate based on each domain.  If you do choose a UCC cert, I suggest not just putting one alternative name on there, but filling up whatever the allotment is for your price point with generic names.  Trust me, you'll need a certificate again at some point, and wouldn't it be handy if you didn't need to go get another purchase approved?


When you install the certificate, make sure to do it both through the role services.  You'll need to specify the certificate in IIS for RD Web Access and in under the RD Gateway Role settings.  See the information here for setting this certificate for RD Gateway:

http://technet.microsoft.com/en-us/library/cc732886.aspx

Now RD Web Access and RD Gateway should work fine on the primary internet line, and they will appear to work from the backup internet line, IF the primary internet line is up, but it won't work without the primary internet line.  The reason is because the DNS entry for the RD Gateway server is hard coded into IIS.  Even though you connected to the RD Web Access on the backup isp, the RD Gateway session will be initiated on the primary isp because that entry is specified as the DefaultTSGateway

You can see more detailed instructions on how to set this setting here:

http://technet.microsoft.com/en-us/library/cc731465.aspx

However this only provides for a single hard-coded entry.  The trick to give us support for multiple isps simultaneously is to modify the underlying asp coding.  Open IIS, browse to Default Web Site -> RDWeb -> Pages -> "en-us" and select "Explore" from the action pane on the right.  Finally edit the file "Desktops.aspx"

Find this line:
DefaultTSGateway = ConfigurationManager.AppSettings[“DefaultTSGateway”].ToString();

And change it to:
DefaultTSGateway = Request.ServerVariables[“SERVER_NAME”].ToString();

This tells IIS to use the name of the server as requested from the client.  As long as RD Web Access and RD Gateway are running on the same server, this should be correct.

These instructions vary slightly for 2008 non-R2, but should be close enough to still follow.  The skinny is that everything is named TS instead of Remote Desktop and the IIS folder is TS instead of RDWeb.

Credit:
In addition to the websites listed above in this article, information was gathered from numerous other unmentioned websites.  This question, and the solution, were originally posted by myself in the Microsoft Partner Forums.  You can find the original thread here:
http://social.microsoft.com/Forums/en-US/partnerwinserver/thread/bb2f49f0-21eb-4407-a33f-19b1de0ff285

Restore from formatted offline files database

Congratulations, you fixed offline files syncing at the expense of the last six months of work for a company executive.  They've given you an  hour to restore their files or to pack up your stuff.  Your frantic internet searches give you some false hopes, but you start to realize your screwed.

Not quite yet!  Highly Unsupported has one last option for you that might just save you from having to get your interview suit dry cleaned.

Windows stores offline files in the folder: C:\Windows\CSC.  The folder is locked down to prevent access from any interactive user.  However if your files are still in there, you can follow numerous instructions online to simply take control of this folder and browse to the files you need.  Or alternatively you can use the psexec method below to hack into it without needing to forcibly take control.

But if you're gone through the trouble of formatting the offline files database, your files won't be there anyways. Your one last hope is one feature Microsoft added with Windows ME, System Restore.  It's never done me any good to actually fix a broken operating system, but it can save you now.

First off, from the afflicted computer, run "vssadmin list shadows" to see if you even have any restore points.

If you have some restore points from before you blew away the offline files cache, and after they created the files, you are in business.

You'll need volrest.exe and psexec for these next steps.  volrest.exe comes from the Windows Server 2003 Resource Kit Tools.  Don't worry though, it'll install and work just fine on Windows 7 (just ignore the incompatibility error).  You can download the Resource Kit here:
http://www.microsoft.com/download/en/details.aspx?id=17657

Grab psexec off http://live.sysinternals.com .  If you don't know what PSEXEC is you should spend sometime to find out after you've saved your job.

The reason we need psexec is because while you could take ownership of the CSC folder which is presently in the operating system, you have no way to take control of the one inside of the restore point.  Microsoft, trying to provide security through obscurity, doesn't let you restore folders you don't have access to, but as administrator that's merely a hurtle.  Run this command to create a cmd window running as nt authority\system

psexec.exe -i -s -d cmd

In XP you could have used the "at" command with the /interactive flag to have accomplished this same thing, but again, Microsoft made it slightly more difficult for "security".

Now the fun part.  Use volrest to restore the CSC directory.  Volrest only works with UNC paths, but that's not an issue, the administrative share provides you with the unc path you need.

volrest \\localhost\c$\windows\CSC /s /e /sct /r:C:\temp\directory

This will restore a copy of every file under the path C:\Windows\CSC for every restore point which has those files in it.  If you have a lot of restore points, you could end up with a lot of files.  The /sct flag date stamps all the files, so you can quickly sort out which is the newest.

Now, copy the files back to the proper locations and make sure the offline files sync is working properly.


Credit:
Information for this solution was collected from numerous websites to generate a complete solution.  Special thanks also needs to be extended to Jim Banach whom not only created this problem in the first place, but was the primary force in discovering this solution.

Ode to the Blog

Congratulations, via a matter of hapless clicks, you've discovered your browser inexplicably displaying this web page.  Let me be the first to assure you that your back button is fully operational, and escape is just a few panicked clicks away at any time.

Being as this is my inaugural post, I suppose I should provide some context concerning my decision to begin a blog.  Though, I think possibly it's better to start with why I've waited so long to begin.  The rampant narcissist teenage angst which pervaded my and many of my friend's LiveJournals left me with a poor perspective on blogs as a communication mechanism.

A decade later my natural aptitude for problem solving lead me into a career as a fixer of problems, specifically IT issues.  The complexity and ever changing nature appeals to the side of me which craves challenges, while the constant deluge of catastrophe provides plenty of opportunities to play hero.  In this process, I've spent countless hours on the internet, exploiting google to replace the need for me to actually be knowledgeable on a subject. Unfortunately, over and over again I found someone whom posted an issue almost identical to mine, only to follow it up with "Thanks, I fixed it", if they followed up at all.

And I realized, I'm one of the worst offenders.  On many an occasion I've found something after countless hours of putting together bits and pieces of poor documentation, or went off on original research.  However soon as I finished, I made no attempt to record the answer for posterity.

That doesn't mean I'm restricting this blog purely to paying my dues to the collective knowledge.  I expect I'll throw in some additional material with questionable correlation to the central theme based on my whims at that moment.  Hopefully it'll all be interesting, but I can assure you that it will all be highly unsupported.