Blog du Tristank : Terminal Server

Every Windows Admin Should Know: Template User vs Mr Nobody

tristank — Thu, 08 Mar 2007 19:28:00 GMT

Raymond beats me to the punch (mine was going to be rant-i-er, but five times* as funny), on how the HKEY_USERS\.Default, despite having the word "Default" in the key name, isn't "The Default User" from which all others are initially spawned.

It's possibly the most frequent misconception I've hit in the user profiles space (which I don't really work in any more, but did quite a bit for a while there).

I even argue with colleagues about it from time to time; the most reliable way to win the argument is by loading up the NTUSER.DAT in the Default User Profile (that's the one on disk - C:\Documents and Settings\Default User) and modifying a value there, then creating a new user and noting the new value is part of the new profile. "Ohhh," they say. "You're so awesome," they say. "You look amazing too. Have you been working out?"

Where was I? Ah, right - Raymond calls the on-disk guy the template user; seems like a good name.

My pet name for .Default is "Mr Nobody". If I thought I could swing it, I'd get the key renamed to .Nobody, but there's buckleys of that happening.

Windows 95 might have used Mr Nobody differently (back then, called the CancelMan, cos you could log in to the default "profile" just by hitting Cancel at the password dialog, unless... steps... had been taken - anyone else have loads of fun with POLEDIT and the CancelMan in '95?) in a profiletacular way, but profiles weren't on by default anyway, so I might just be misremembering and blathering.

NLB Ain't Application-Aware

tristank — Thu, 01 Mar 2007 09:04:48 GMT

It's been ages since I touched on anything wibbles-related, but I realized I'd neglected a very common query:

If one of my applications is under load, will Network Load Balancing route/move/transfer all the additional load to the other server?

No. As long as the box still lives (or more specifically, the NLB driver is able to send heartbeats and receive incoming IP traffic), NLB will keep on allowing connections.

The load rules are used to govern the rough percentages of connections, but any web developer will tell you that connections don't necessarily map to load.

From NLB's perspective, it doesn't even matter if your application isn't running any more. It's simply there to filter out all the traffic you don't want to hit that machine. (Recall that getting NLB working basically means fire-hosing all incoming traffic at all members of the NLB cluster, and relying on each node to know which bits of traffic to ignore, and which they "own").

For Terminal Servers, this means that if one TS is overloaded and can't accept any more connections, NLB doesn't know or care. IIS is similar - if one Web app is chewing 100% CPU, don't expect connections to be balanced to another server based on that fact alone.

This leads to the existence of health-monitoring utilities that will pull a box from an NLB cluster (i.e. DRAINSTOP it) if they detect a problem with a key app (much as ISA Server 2006 and 2004 do when they detect a problem with an array member).

Technet describes this in more detail here.

(Thanks to 'softie Daniel Taylor for digging up the relevant links and mailing them to me.)

Windows Vista FTW: Cleartype over RDP

tristank — Thu, 21 Dec 2006 09:46:21 GMT

One of the little things I love about Windows Vista is that I'm able to use the RDP client without The Jaggies.

I use Consolas in Visual Studio and elsewhere, and as Jeff pointed out a while back, it's just not built for non-Cleartype environments.

I mostly use RDP on my home WLAN, but even across the Internet, I find the benefits of font smoothing compelling enough to spend the extra bytes on it, even on my dodgy cable connection.

So: Vista Remote Desktop Client for the win!

(as far as I know, it works only to Windows Vista-level RDP servers).

KB Highlight: WMICore update for Windows 2000 SP4

tristank — Tue, 19 Sep 2006 17:37:18 GMT

If you like to live on the cutting edge of the previous version of Windows, there's a problem that seems to creep up that I've seen in a couple of environments before.

VBScript not working in a hanging-kind-of-way (possibly including ASP, definitely logon scripts, and typically just about any general scripty bits) is usually a dead giveaway that you're running into this problem:

A deadlock occurs when a program that uses WMI calls the LoadLibrary() or the FreeLibrary() function in Windows 2000
http://support.microsoft.com/?id=834010

Assume that a Microsoft ASP.NET program or a program that uses a Windows Management Instrumentation (WMI) provider makes direct or indirect calls to the LoadLibrary function or to the FreeLibrary function to load a DLL. Then, the DLL calls the RegisterTraceGuids or the UnRegisterTraceGuids function in the DllMain export function. In this scenario, a deadlock may occur in the ASP.NET program or in the program that uses a WMI provider.

For example, Microsoft Internet Explorer, Control Panel, and the Add/Remove Programs tool may stop responding (hang) after you install Microsoft Windows 2000 Service Pack 3 (SP3) or Service Pack 4 (SP4). When you stop the Remote Registry service, this permits the programs that have stopped responding to resume. This issue may occur in environments where a remote performance monitoring solution, such as PerfMan or SiteScope, is installed.

Also, when this issue occurs, Microsoft Visual Basic scripts may not run correctly, and you receive no error message. Additionally, the Task Scheduler tool may not run.

If you've just made some sort of monitoring change (or just implemented some monitoring or management software) and now logon scripts, ASP, ASP.Net or similar aren't working quite right any more, I'd suggest trying this on an expendable test machine first. It can save you time.

On the subject - the hotfix article itself is a "call PSS" distribution fix, but a quick search of KB reveals that there's a publicly downloadable version of that wmicore.dll update included in the Update Rollup for Windows 2000 Service Pack 4-based Server Clusters (885912).

If it fixes the problem, yay! If not, it's not your problem, so keep troubleshooting.

PAE and VMM... For Parky

tristank — Fri, 26 May 2006 16:50:00 GMT

Well Parky, you asked, so I'm going to try to answer!

The way I think about PAE is that it kinda works a bit like a stonking great in-memory pagefile might. It doesn't change the game for 32-bit applications, but it does give the OS more headroom to manage them.

Without PAE, any memory over 4GB can't be "seen" by the OS itself, so it can't be used.

With PAE, the memory manager can see all the installed memory, but it doesn't change the per-process or kernel limits.

So if, for example, you ran 3 database programs at once, each of which used their entire 2GB user address space, with a PAE box and 6+GB, the whole lot would potentially fit into memory (assuming your kernel didn't mind getting squeezy).

So, in really short form: almost the same architecure, but more RAM!

And you're right on the other front - after a certain point on a 32-bit Terminal Server, the limiting factor is likely to be kernel address space, so if you're eyeing PAE as a possible answer and you haven't yet deployed the box, consider going x64 instead.

Now, here's the other attempt I was working on, but un-fact-checked and likely subtly (or grossly) misleading - think of it as a work-in-progress lie. For the actual story, hit "Windows Internals, 4th Edition", by Mark Russinovich and David Solomon.

I'm unlikely ever to finish this, so I figured I might as well post it for... um, well, fun, and to show I care enough to try* (for a while) :)

--------------

Trial #1: Intro to PAE using Sheep as an accessible metaphor

32 Bit Addressing = 386

The CPUs we know and love today are all descendants of the i386. The '386 was a chip that had 32 address lines, which is a techy way of saying that it could talk to up to 4GB RAM. 32 bits = 4 billion possible individual memory locations.

36 Bit Addressing = PAE

Physical Address Extension is a 36-bit addressing thingamabob that got tacked onto Pentium Pro and later CPUs.

PAE is cool, because the extra 4 bits mean that the processor can talk to a whopping 64GB of RAM, instead of the paltry 4GB that seemed so cool just ten short years ago. Heck, in ten years' time, my phone will probably have 2GB onboard!

Enter The Sheep Metaphor

In short: each process gets a 4GB address space, and the lower 2GB is a play area unique to that process. All processes share their address space with the same kernel, which is the upper 2GB.

Let's say that Sheep is our 32-bit Windows program. When Sheep is started by the OS, it'll be plonked into a 2GB field in which it can play, with a small amount of nasty barbed wire near the very bottom, and a big wall with a tiny window near the top.

The Kernel memory area is another 2GB field beyond the wall, with a sign tacked to the front "All that 2GB field is yours, except this 2GB here. Attempt no grazing here."

Any other programs you run get put in their own totally separate 2GB field (say, SkyscraperBuilder.exe) but they all see the same Kernel field. It's a bit like the dead people in the Sixth Sense (honestly, if you haven't seen it yet, you need to stay in more) - they can't see each other, but the kid (Kernel Kid™?) can see them.

With me so far?

All This Could One Day Be Yours (but you have to allocate it)

Windows doesn't just hand each process a fully allocated 2GB field of memory - (count the number of processes running on your computer at startup; now imagine having to install 2GB of RAM for each process to run!) - it gives it just enough to get it loaded, and then the process has to actually ask for what it needs.

A Sheep might only use less than 1% of its field while it's wandering in a small area and grazing, whereas the SkyscraperBuilder is likely to try to use all the space it has available, and subsequently harangue, harass and attempt to blackmail the planning authority for more.

But at the beginning, they both believe that the field is empty, and they just start asking for memory.

Virtual Memory

Virtual memory - to cut a very, very involved story of lies and deception rather short - is how the OS manages to allow each application to request and use memory that all seems nice and contiguous to the application, but is actually "backed" by memory in a physical location elsewhere - and that "elsewhere" can be somewhere else in RAM, or on the hard disk, in the pagefile.

The Kernel address space itself is virtualized, though k-mode components are able to "look behind the curtain" if really necessary.

In a situation where you've got less memory than 4GB, VM means that everything gets to actually run, while having this wonderfully seemingly neat memory area to play in, and room to grow.

If you've got the whole 4GB (which is our theoretical maximum at this point in the discussion) and a bunch of tiny programs, everything's going to go swimmingly.

But just flip that on its head for a second - just say your requirements were greater than 4GB. Say that the amount of memory actively used by all the programs on your computer (called the "Working Set") exceeds 4GB. Say that all up, you really need 6GB in RAM at one time, across a bunch of processes.

The CPU can only use 4GB total… so even if you somehow drop 8GB into the machine, you're in for some paging (hitting the hard disk to swap memory in and out of physical RAM) without PAE; the OS can only keep track of so much memory.

But Enable PAE, and whop! The CPU can now use however much RAM you've got in the box (up to 64GB), so less paging happens. The kernel/user split is still the same - we're still talking 2GB user space per application and 2GB kernel space, so it's business as usual to each process on the machine - it's just that the virtual memory manager can now use all the RAM in the box to satisfy demand before having to go to the page file.

64 Bit: It's When, Not If

tristank — Wed, 10 Aug 2005 09:44:00 GMT

Harold raised the question, Clive riffed on it, and now I'm going back to the original question with this:

At the moment, is it even possible to buy a performance chip that isn't 64-bit capable?

Any AMD Athlon64 or Opteron is AMD64-capable; Intel Xeons have been for a while, and EM64T is moving into their desktop offerings too, with notebook variants on the horizon.

So the question isn't about whether or not to buy a 64 bit chip - chances are you will be buying an x64-capable chip anyway when you next purchase one* - the question is really about when to actually throw the switch and move to a 64 bit OS.

For most consumers, that's probably not just yet. I think it's important to acknowledge that, because bluntly, it's not like we're going to be selling a copy of X64 to my parents, and right now, we shouldn't be trying - while it's not a whole new architecture (unlike, say, Itanium), there are still 32 new and previously unseen bits, Drivers Will Need To Be Recompiled, Recompilation Takes Time And Is Not Always Feasible, and as a result, Not Every Driver Is Available In An X64 Version At The Moment.

The ability of users to exceed the capacity of the 32 bit architecture isn't yet widespread outside of niche environments, but we're not too far off that time: games regularly run best with at least a gig of memory (and let's face it, games are the real driver of the leading edge of consumer adoption, right?), and more is usually better. We're not yet at the tipping point of the old 640K mark - where all the band-aids had been applied, but the patient was still very much at death's door - and that lessens the impetus for the consumer space.

So IMHO, right now, the cost/benefit doesn't typically work for consumers. Yes, I run Windows X64 Edition at home, but I don't have any super-concrete reasons for doing so that require bits 33-64 to be present (at least that I'm aware of at the moment). There are a few games taking advantage of the AMD64 extensions, but that's about it for now, for me.

Servers, on the other hand, can already eat all the memory we throw at them, and don't typically have the handicap of having to run, say, my Dad's aging scanner, so for high-performance large-memory workloads, moving to 64-bit is a no-brainer, especially if you can do so on hardware you've already purchased.

On x64, being able to run a 32-bit Large Address Aware process with a full 4GB of user address space is often a compelling enough benefit on its own, but using a 64-bit native image lets you use... um, well, it's a really, really big number, something like eight thousand gigabytes, if you can jam that much in your machine.

And multiuser scaling on Terminal Server - yes, for 32 bit applications - is from all indications Where It's At on X64 at the moment. In the Terminal Server space, we've been constrained for a number of years by the 32-bit architecture (and whether to enable PAE, and whether we end up constrained by System PTEs or Paged Pool or NonPaged Pool, and so on), and the increased kernel headroom buys increased scalability. Nice.

So there's my $0.02 x 2.

* - Intel's processor chart seems to show gaps in the EM64T capable lineup, but it's hard to read on a single screen, and I've given up. Anyway, the point is, likelihood of a given chip being 64-bit capable increases as time goes on.

** (don't bother looking for a **, there wasn't one in the body) And I plan on going X2 as soon as the prices drop to something a little more palatable. Like, 300-400 bucks palatable, for something that "doubles" my 3500+.

Terminal Server / Remote Desktop DoS Issue

tristank — Tue, 19 Jul 2005 03:26:00 GMT

Via TonySo:

http://www.microsoft.com/technet/security/advisory/904797.mspx

Our initial investigation has revealed that a denial of service vulnerability exists that could allow an attacker to send a specially crafted Remote Desktop Protocol (RDP) request to an affected system. Our investigation has determined that this is limited to a denial of service, and therefore an attacker could not use this vulnerability to take complete control of a system. Services that utilize the Remote Desktop Protocol are not enabled by default, however if a service were enabled, an attacker could cause this system to restart.

Sounds like a low-value attack, but an attack nonetheless. Check out the advisory article for mitigation details while we work on a fix; an additional workaround might be to temporarily adjust the port you're using for RDP from the default (security through obscurity - if an attacker took the time to scan all available ports, they'd still probably be able to easily identify the RDP port) - you can do this without modifying a back-end server if it's done with ISA 2004 (ignore the TSWeb bits, it's the port numbering we're interested in), and/or to filter that port based on known/trusted incoming IP addresses.

Update: Noticed Susan had a similar thought about it - the RDP proxy used for RWW in SBS 2003 runs on a different port (*speculation with little-or-no-merit warning* who knows, might not even be affected by the same issue...).

Windows Server 2003 SP1 Automatic Updates Blocker

tristank — Wed, 22 Jun 2005 01:56:00 GMT

Like XPSP2 before it, Windows Server 2003 Service Pack 1 is going to be distributed via Automatic Updates.

The start date for automatic updates is July 26, 2005.

If you'd rather move at your own pace over the next year, you'll want to look at the Blocking Toolkit, and the following information:

http://www.microsoft.com/WindowsServer2003/evaluation/news/bulletins/ws03sp1blockertool.mspx

FAQ: http://www.microsoft.com/windowsserver2003/evaluation/news/bulletins/ws03sp1blockertoolfaq.mspx

The blocking mechanism expires on March 30, 2006.

And the Windows Server 2003 x64 version is out there too!

tristank — Wed, 30 Mar 2005 13:27:00 GMT

Versions of Microsoft Windows for AMD64 and EM64T are now available:

Windows Server 2003: http://www.microsoft.com/windowsserver2003/evaluation/trial/default.mspx

MSDN Subscriber Downloads have both versions available now, under Windows Server 2003 and under Windows XP Professional (not the SP2 branch) respectively.

X64 versions are built from the same code base as the 32-bit Windows Server 2003 SP1.

Windows Server 2003 SP1 Out Now

tristank — Wed, 30 Mar 2005 11:55:00 GMT

http://www.microsoft.com/downloads/details.aspx?FamilyId=22CFC239-337C-4D81-8354-72593B1C1F43

If you've been waiting for this - it's finally baked!

New Feature: RDP over SSL with Windows Server 2003 SP1

tristank — Thu, 24 Feb 2005 22:49:00 GMT

Release Candidate 2 for Windows Server 2003 SP1 is available to test from microsoft.com, which means RTM can't be that far away!

A new feature in SP1 (at least, present in the RC2 build of SP1) that's been causing some confusion is RDP over SSL - a new option for Terminal Services that should provide server authentication for TS sessions, preventing MITM (man in the middle) attacks while providing a new option for encryption.

Up front - RDP over SSL is not a firewall traversal technology. It doesn't mean you're using Web protocols to do RDP. To rephrase, it's not "RDP over HTTP", it's "RDP with TLS authentication and encryption over TCP" - it still happens over TCP port 3389, as RDP usually does.

For the screenshot at left, I don't have a server certificate installed on my test VM at the moment, but I'm told that when you do, the SSL options become available.

This led to a few questions on how you server publish RDP/SSL with ISA Server, and the answer is: Exactly as you'd publish RDP normally with an ISA Server - using Server Publishing (ISA 2000 version is here).

Essentially, ISA creates an opaque TCP connection between the client and the server, and the encryption and authentication occurs directly between client and server in a manner that ISA can't inspect (except at the IP traffic level).

Ninja Feature: Remote Web Workplace in SBS2003

tristank — Thu, 14 Oct 2004 11:28:00 GMT

Remote Web Workplace is (in my humble opinion) The Ninja Feature of SBS2003. In fact, it gets the inaugural EBTDF Ninja Feature award for being so cool.

Thanks to Susan Bradley for putting me on to it.

Let me say right now - if you're using Small Business Server 2003, and you were thinking of fiddling around with TSWeb, hacked connection pages and port mappings, don't!

Use Remote Web Workplace instead. It's (often) as simple as "running the CEICW", which SBS people tell me that other SBS people will understand (the Email and Internet Wizard).

What Is Remote Web Workplace?

It's a web portal through which authenticated users can access:

- Remote Desktop to internal WinXP Pro boxen and Terminal Servers (on tcp port 4125)
- Outlook Web Access
- Sharepoint (on port 444)

In short, the idea is that using one or all of the above, you can do anything you can do while in the office, from anywhere (alright, close to anywhere!).

The portal looks a lot like this when you're connected as a user:

Now, I'm assuming everyone's familiar with OWA; if not, there's a plethora of information on it, ready for the searching (start at http://www.microsoft.com/exchange/owa/) - in really simple terms, it's a browser-based version of Outlook connected to your Exchange server.

While OWA's cool and all, the bit I'm really impressed/happy/interested with is the Remote Desktop access to internal computers. Without having to hax0r the TSWeb connection page or forward ports manually!

Not Your Father's TSWeb

In real simple terms, RWW provides an RDP Proxy for incoming RDP connections. So the same external port can be used by multiple internal clients, which isn't otherwise possible.

RDP is Remote Desktop Protocol. It's the protocol that all the little TS Clients use to draw the screens from the big Terminal Servers, and also how the Remote Desktop client connects to a Windows XP Pro machine with Remote Desktop enabled.

Once you've got it set up, here's how RWW works: (note: my brand-new understanding - if in doubt, believe the docs over me).

Using IE, you make an HTTPS connection to the Remote website on the SBS box (https://www.example.com/remote).

You submit your user credentials (which are protected from external snooping using SSL), and these are used to authenticate you and work out what options you'll be given on the RWW page.

Once authenticated, you're staring at something akin to the screenshot above.

You click the "Connect to my computer at work" item, and are presented with a list of Remote Desktop enabled computers in the Active Directory:

You pick the computer you're interested in, and hit Connect.

What happens here is even more interesting: you're directed to a TSWeb connection URL, the TSWeb ActiveX control fires up (it may need to be installed on the way), and then it connects to the RDP proxy on tcp port 4125 - not the regular TS port of 3389 (remote administration of the SBS box itself still happens on 3389, though).

The RDP Proxy creates a connection to the target computer, at which point you're prompted for your username and password again to log you onto the computer (unless you've ticked the "Log on to selected computer" option, as above). Then, you can do whatever you want, as if you were sitting at your work PC. Magic.

I need to note at this point that you're using straight RDP from the client to the SBS server, with RDP encryption (RC4, up to 128-bit keys) - the RDP is not additionally encrypted over an SSL tunnel - the connection to the RWW portal is made over SSL, but this is a different connection again.

This does mean that if you're on a network that doesn't allow 4125/tcp outbound (and let's face it - it's not exactly a port everyone recognizes yet), you might need to politely request that you're allowed to use it. Please. Nice Mr Firewall Man.

More info on RWW:

For more information, start with the Support Webcast. Then set it up!

!Highly Recommended! Remote Web Workplace: The Support Webcast
http://support.microsoft.com/default.aspx?kbid=833983

(if the images seem familiar, well, that's because they are...)

Help Your Team Work From Home (without breaking their legs)
http://www.microsoft.com/australia/smallbusiness/issues/running/productivity/home.mspx

Matt Hyunh's mentioned RWW before - in fact, to date a whopping 50% of his blog posts have mentioned it. Might be worth watching!

It's good. Go play.

TSWeb: Sample TSWeb Pages to Connect To Non-standard RDP Ports

tristank — Fri, 03 Sep 2004 08:17:00 GMT

If you think you're experiencing deja vu, it's because this was also covered in Publishing RDP Servers with TSWeb and ISA 2004 , but I thought I'd do some housekeeping and make a separate post on the pre-fiddled TSWeb connection pages.

Short version:
The TSWeb (aka TSAC, Remote Desktop Web Connection) package includes a sample Default.Htm file that shows you how to use the TSWeb components, but it doesn't allow the user to specify the port. Not everyone needs to do this - it's usually only useful if you're using multiple external ports on the same IP address, or if you change the default RDP connection port for another reason. The samples on this page show you how you can use the scriptable RdpPort property of the TSWeb ActiveX control to connect to another port.

Longer blurb:
The package includes essentially the same default.htm as the - er, default from TSWeb, except there are two zip files within the package, and internally they're both called External.htm. Plus, I broke the formatting on the horizontal fadey bar, and couldn't be bothered messing around with it, so it's been removed. :)

The basic difference is that the modified versions can handle a servername and port, instead of just a server name. The ServerList page demonstrates a selectable list of servers:

while the ServerTyped version lets the user manually type the name and port of the server using the servername:port format:

(this doesn't work using the regular TSWeb connection page)

They're both fundamentally based on the same file, and fiddle in the same way with the AdvancedSettings2.RdpPort property to work their magic - just with comments in different places. They're just an example, all care taken, but no responsibility accepted. There Might Be Bugs*. But they might make your life a teeny bit easier.

Download the package that contains both versions here.

So, open the package that you want to use, then put the external.htm file in the TSWeb directory on the web server. It won't affect any of the existing files in that folder.

If you're using the selection list of servers file, you'll need to find the EDITEDIT bit of the HTML, and replace the example domain names and ports with your own real domain name (or external IP address, but domains are easier to use and less hassle in case of IP address changes) and port, then save the file.

If you're using the typed version, you pretty much don't need to edit anything.

Note: If you rename either file, you need to find "external.htm" in the text (it's next to an EDITEDIT comment), and change it to whatever name you've given it.

Then, try browsing to http://www.example.com/tsweb/external.htm , and try it out - it should all work.

Publishing RDP (Terminal Servers, XP Remote Desktop) with TSWeb (and ISA 2004)

tristank — Mon, 16 Aug 2004 07:54:00 GMT

My last post on TSWeb (aka TSAC or Remote Desktop Web Connection) continues to be one of my most-hit blogs, so I spent a little time working with the TSWeb default connection page to try to simplify some of the bits that people were asking about. The aforementioned post describes how it works - this is more focused on the "getting it set up" part.

So, here's a quick how-to guide on publishing multiple internal RDP servers using ISA 2004, a single external IP Address and a mildly edited TSWeb connection page that allows you to specify the connection port number as well.

Jump to the port mapping bit
Jump to the new TSWeb Connection pages bit

You Will Need:

ISA 2004 installed as an edge firewall (Server Publishing of internal IPs must be available)
NB if your router/firewall/edge device can do Port Address Translation, it'll work just as well, but the specific steps here are for ISA. If you have additional external firewalls, further configuration will be required.

A Web Server with the TSWeb package installed on it (an internal desktop may also be fine for this).

The hacked-up connection page (sorry about the formatting, it's just an example!) in the TSWeb directory (by default, c:\Inetpub\TSWeb, I think).

Before We Start Fiddling

Check that the regular TSWeb works correctly within your network.

Web Publish the TSWeb directory

If you're not web publishing and are more an "MSTSC" kind of person, then skip this step. Otherwise, if you want to actually use the Web connection software, you need to publish the TSWeb files.

Set up a Web Publishing rule that exposes the /tsweb/* folder from the internal Web Server to the External network. (It's good to keep it locked down to just that folder and contents if that's all you're publishing).

Test the Web Publishing rule - from the Internet, you should be able to connect to and display the connection page, but actually connecting to any internal computers should not be possible (yet). If you can't get to the www.example.com/tsweb page at this point, troubleshoot that first.

Server Publish Each RDP Server On Its Own Unique Port

ISA 2004 allows you to adjust port assignments while publishing, and that's what these steps show you how to accomplish: we're going to map the external IP address of the server to the internal IP address of the client, using slightly different ports: for eg, www.example.com:3390 will map to 10.0.0.15:3389 (the default TS port, so no changes are required on the client). The next one might be 3391, 3392 and so on - it's basically arbitrary, and up to you.

If you have another firewall that can do Port Address Translation, these steps won't apply directly, but the theory's the same.

1. Right-click Firewall Policy, create a new Server Publishing rule. Call it something descriptive, like "RDP to Barry's PC", or "TS01 ext port 3390".

2. Type the IP address of the machine on the internal network, hit Next.

3. Pick the RDP Server protocol, then click the Ports... button.

4. This is where the magic happens - unlike ISA 2000, you can modify either end of the connection to point at a non-standard port. In this case, we're just incrementing the default RDP port 3389 by one, to 3390. Firewall ports are the "listening" port for incoming traffic, Published Server ports are the ports for the internal server.

5. When you've set the above, choose the External network to listen on (it will only work for connections to the External NIC)

6. When you're done, the rule should look something like this (before clicking Apply - don't forget to click Apply before trying it!)

Once the internal machine is Server Published, test it with the standalone RDP client from an external client (Start, Run, MSTSC) (we're not testing the Web version yet). On RDP clients version 5.1 (XP) and above, it should now work when you type www.example.com:3390 into the connection dialog box. Note that the Web version does not support this syntax by default, so the out-of-box Web version won't work yet. That's what the example page below lets you do!

If you're having a problem connecting using MSTSC externally, you need to troubleshoot and fix that problem now. Assuming everything else works, one vaguely-likely possibility is that the internal server is not a SecureNAT client (that is, it doesn't route unknown IP addresses back through the ISA Server using its Default Gateway).

If you're in this situation but happy with your internal routing, and don't want to reconfigure it for the published server, you can modify the rule properties so that requests appear to come from the ISA Server computer, rather than from the Internet (the default for a Server Publishing rule - cool thing, in 2004 this is a per-rule setting, not a global setting as in ISA 2000).

Alternatively, look at the ISA Server Monitoring snap-in, Logging section to work out whether a rule is preventing access.

Configure The External Connection Page

I hacked up the TSWeb-supplied default.htm file to produce an external.htm file (actually, two files with the same name in different zip files, in the same zip file. Got it? You just use the one you like better).

The basic difference is that the modified versions can handle a servername and port, instead of just a server name. The ServerList page demonstrates a selectable list of servers:

while the ServerTyped version lets the user manually type the name and port of the server using the servername:port format:

They're both fundamentally the same file that fiddle in the same way with the AdvancedSettings2.RdpPort property to work their magic - just with comments in different places - and they're just an example, all care taken, but no responsibility accepted. There Might Be Bugs*. Download them both here.

So, open the package that you want to use, then put the external.htm file in the TSWeb directory on the web server. It won't affect any of the existing files in that folder.

Then, try browsing to http://www.example.com/tsweb/external.htm , and try it out - it should all work.

Good luck...

[Update 17 Aug 2004] And wouldn't you know it - Tom's had this out for a while, though focused on the port mechanics rather than the Web bits. And I thought I was being so novel!

Communities Blog Portal Now Open! With Keyword RSS Feeds!

tristank — Sat, 10 Jul 2004 19:16:00 GMT

http://www.microsoft.com/communities/blogs/PortalHome.mspx

Coolest feature: the ability to fashion a keyword/category query into an RSS feed across all Microsoft blogs. If you're only interested in certain things (and personalities be damned!), you can sign up for the keyword feed. (And if you're really serious about losing personality, try running it through a text-to-speech program afterwards, or removing all the adjectives).

Bit that looks like it needs work, but might not actually need work: The categorization gets pretty coarse (for someone that plays in the Windows space, having “Windows” as a category is a little on the “too general” side of the happy fence), and in some cases blogs aren't (yet) categorized appropriately (I'm sure we'll work on that) - but you can easily overcome that by throwing in a keyword or two when picking a category. Heck, my category titles look like blog titles to the categorizer(TM), so I'm going to have to edit them a bit now!

Tim's one of the people behind the project, and he's interested in your feedback, so drop him a comment!