Transitioning From VB Script to Powershell

VB Script is still around and will be for quite a while yet.  But current Windows technology is all about Powershell.  As well it should be, as PS is vastly superior in many, many ways.

However, a lot of us still have old VB scripts hanging around, probably doing production work… and what I’m about to show you may be the trickiest part of porting those old scripts over into Powershell.

As you probably know, Powershell fully harnesses the power and flexibility of .NET, while VB Script was only capable of working with COM objects.  Almost everything that can be done with COM objects can be done faster and easier with .NET.  (For the foreseeable future at least – I hear COM is making a bit of a comeback in Windows 8…)  However, Powershell is still fully capable of working with COM objects too.  What that means is that those of you who are still more comfortable with VB script or have a lot of script to port over in a hurry, well, you don’t have to worry about finding .NET equivalents for those COM objects. (Even if there might be a better, more Powershell-native way of doing it.)

Let’s take Microsoft Cluster Services for example.  Here’s what you would see in a VB script that deals with cluster resources:

Set oCluster = CreateObject("MSCluster.Cluster")

 In Powershell it’d be something like this:

$cluster = New-Object –COMObject MSCluster.Cluster

 Now  you have your cluster object.  Want to see what all members it has?  (The properties of it + its methods/what all it can do?)

$cluster | Get-Member

 Alright well I see that $cluster is basically an object collection that has, among other things, a ResourceGroups object in it, so let’s open that up:

$ResourceGroups = $cluster.ResourceGroups

 And then do a $ResourceGroups | Get-Member to see what we can do with that: 

PS C:\Users\ryan> $resourceGroups | Get-Member

   TypeName: System.__ComObject#{f2e60706-2631-11d1-89f1-00a0c90d061e}

Name                MemberType Definition
----                ---------- ----------
Delete              Method     void Delete ()
Move                Method     Variant Move (Variant, Variant)
Offline             Method     Variant Offline (Variant)
Online              Method     Variant Online (Variant, Variant)
Cluster             Property   ISCluster Cluster () {get}
CommonProperties    Property   ISClusProperties CommonProperties () {get}
CommonROProperties  Property   ISClusProperties CommonROProperties () {get}
Handle              Property   ULONG_PTR Handle () {get}
Name                Property   string Name () {get} {set}
OwnerNode           Property   ISClusNode OwnerNode () {get}
PreferredOwnerNodes Property   ISClusResGroupPreferredOwnerNodes PreferredOwnerNodes () {get}
PrivateProperties   Property   ISClusProperties PrivateProperties () {get}
PrivateROProperties Property   ISClusProperties PrivateROProperties () {get}
Resources           Property   ISClusResGroupResources Resources () {get}
State               Property   CLUSTER_GROUP_STATE State () {get}

So hopefully this is starting to pique your interest.  With this sort of information you could easily script out whether all the cluster resource groups were on the correct nodes, and even move them if need be.  Pretty neat stuff.

I leave you with this – don’t you hate it when this happens?

F'ed up log

Remote Desktop Services Tutorial #2 (RD Web Access)

Sorry it’s been so long since my last post — I’ve been awfully busy over at that other blog. And don’t even get me started on that whole ‘life’ thing…

For the first installment in this series, see RDS Tutorial #1 (RD Gateway).

If any of the images are too small for you to see, try clicking on them, they might be thumbnails.

Now that we’ve set up an RDS Gateway, let’s try to add RD Web Access into the mix. RD Web Access is a pretty cool little role service of RDS that puts up a secured website that authorized users can access. From this website, the user can launch remote desktop sessions, and even better – RemoteApp programs. With RemoteApp programs, you can either launch applications from the RDS server by clicking on their icons on the RD Web Access website, or if you use Windows 7 or better, you can actually add them to your local Start Menu and launch them as though they were located on your own PC! It’s pretty sweet. For this tutorial, I’m going to attempt to add the RD Web Access role service to the same server that is currently running my RD Gateway. Were this an enterprise environment, I probably wouldn’t do that. For performance and scalability reasons, I’d probably break out the roles to different servers. But this is just a lab and a proof-of-concept. Let’s start by going to Server Manager on our existing RD Gateway server and adding the RD Web Access role service:


It will ask to install some IIS dependencies just like it did with RD Gateway. Just take the defaults; there shouldn’t be any problems with conflicts.



Alright so let’s look at the settings we’ve chosen above. It’s telling us that our new RD Web Access website will be at https://servername/RDWeb. So for me, if you wanted to access my RD Web site from the Internet, its address would be Note that you will still have a “default” website in the / directory. It will have the generic “Welcome to IIS” logo that us IIS users are so familiar with. You might consider adding an automatic redirect that goes to the RDWeb directory from the default site, unless you plan on using the default directory/site for something else. Also notice that the website’s SSL certificate will already be trusted if you access it from the same workstation and if you’ve already followed my RD Gateway tutorial. (And you address it by the FQDN in your browser.) See where it mentions WSRM? Windows System Resource Manager. It’s a nifty little tool that, in my opinion, is best used on servers that will have a lot of clients connected to them simultaneously. That’s because with WSRM you can do things like create system rules that will enforce policies like an equal distribution of CPU power and/or memory to all the connected clients. That way one doofus won’t have the power to adversely effect the experience of everyone else connected to your remote desktop server. But for now it’s outside the scope of this tutorial. We’ll cover it later.


Alright so that’s pretty much all there is to installing the RD Web Access role service. The only thing of note in the above screenshot is that it’s warning us that additional configuration is needed. That’s because we haven’t configured any RemoteApps for publication yet. It will continue warning you about this until you do. We’ll get to that in a bit. So now you have an RD Web Access site running on the same server as your RD Gateway! Below is a screenshot showing you where to find the files if you want to personalize your own RD Web site. You’ll at least want to add your company’s logo and name.




So here I’m just specifying the name of the computer that will host the RemoteApp programs. You can also modify this setting in the web.config files. Since I’m putting all the role services on the same server, I’m pointing to myself. There’s one other setting you can configure: The default port on which RemoteApps will be published. You can change this in the IIS console, or in the web.config for the site:


The interesting thing about this is that I believe this port only matters to internal clients. However, since we’re using an RD Gateway, we don’t have to open that port on our externally-facing firewall. We’re already running an RD Gateway and the RD Web Access website on the same server and on port 443. And now we’re about to be able to transport RemoteApps through 443 as well! That’s pretty freaking amazing if you ask me. How many different services can you squeeze out of one port? Alright, so now we have one final problem. And that is that we don’t have the required role service installed to host RemoteApp programs! That role service is RD Session Host. I’m just going to go and add it to this same server. Like I said before, I’d distribute the load more in an actual production scenario, but this is a lab so what the hell. If you do install RD Session Host on a separate server, be sure to specify it on the configuration page on RD Web Access, as was shown earlier.


Pictured above is just me adding the RD Session Host role service. It’s asking me if I want to enforce NLA. I like security. And I like enforcing. The next step will ask you about CALs. Client Access Licenses. This is that part where I was telling you about how you can only have two users logged in to a device “administratively” at once, but you can have bunches of users simultaneously connected to a proper RDS server. The downside is that you have to pay for that. At least you get to choose how you wanna pay. Per device or per user. I would go with per user, so that I can connect from any number of devices. However if you have several users that share the same workstations (like shift workers in an office) from which they connect to the RD session host, it might make more sense for you to do it per device. If you choose “configure later,” it will at least let you try it out for a few months before it stops working.



The next step asks about which AD groups I want to allow to connect again, just like it did for the RD Gateway. And again, I added the “RDS Users” group to that list. On the next step, pictured above, we configure which parts of the “Client Experience” we want to enable for our remote users. Each of these options will require more bandwidth and will demand more performance from your RD Session Host. And what the hell, why not… let’s drive this poor VM into the ground! I’ll probably be the only person connecting anyway. Except for that kid in China that finally hacks in. After the installation is complete, you’ll need to restart, and it’ll take a couple minutes extra to reboot as there is a lot of new configuring being done. Your server is now a full Remote Desktop Server. The important thing to remember is that from here on out you need to put that server in “RDS install mode” to install applications, unless the installation is a modern .msi package. You can research and find out exactly what it does, but basically it’s an old mechanism that just ensures that the application is installed in such a way that is friendly to being used by multiple users. You now also have a RemoteApp Manager added to your Server Manager console. Now let’s go and try to publish some RemoteApp programs. . .


The first thing I noticed was that it wanted to use a certificate for RemoteApp programs. So I gave it one. The same one that I was already using for the RD Gateway, and was issued by my enterprise CA.


Next I’m going to specify that the client should connect using my RD Gateway, bypassing the gateway when internal. Perfect. This part is crucial if you want to be able to access RemoteApp programs from the Internet, as remember you can’t get through on ports 3389 or 5504 from the Internet. Next I’m going to go to the local Users and Groups. Notice the two new local groups at the bottom, TS Web Access Admins and TS Web Access Computers. Domain Administrators are administrators by default, whether they are in that TS Web Access Admins group or not. Now even though the other group says “computers,” I went ahead and put my custom RDS Users group in there anyway.


Finally we’re ready to add a RemoteApp program. In your RemoteApp Manager, just right-click and add a RemoteApp program. I don’t have anything interesting installed, so I guess we’ll just add Powershell just to test if it works. At this point, you’re ready to connect to your fully-functional RD Web Access website from the Internet!


There’s your RemoteApp program! Also notice down in your taskbar, an interesting little icon popped up that you only see when accessing RemoteApp. It’s a part of the Windows 7 system that allows you to add programs to your Start Menu as if they were local, but are in fact running over that connection through our RD Gateway. Clicking on the Powershell icon will prompt you if you’re sure you want to run this program over a remote connection. Make sure that it correctly specifies both a remote computer name and a gateway server name, which in my case are one and the same. It will then attempt to connect, and you might get prompted for credentials to the RD Gateway server. One oddity that I noticed was that I got my default domain policy greeting message like you would get when normally logging on to any domain server, but it was in an odd resolution, and I had to click OK. My first thought is that it would be easy to wiggle around that with some group policy work, but it doesn’t bother me that badly.


Alright so your remote application launched! Check it out! It looks and feels like it’s running on your own local workstation. Notice down in your taskbar that the application’s icon has a little “remote” symbol on it. The neat thing I tried to convey with the Powershell command I typed in is that it is retrieving information about the remote system, not your local system. And all of this is taking place over an SSL tunnel on port 443. Alright, so that’s all I have for today. Feel free to contact me if you have any feedback or to tell me that something I did could have been done better. ‘Till next time!

IPv6 Tunnel on your Cisco Router!

Heya, it’s me again. I thought I’d throw out a quick and dirty post since it’s been a while. Plus, I have a topic that’s more network-related, which is nice for this site since I know it’s trying to stay mainly networking related.

ISPs are still slow to adopt IPv6. Very few of us can say that we have globally-accessible IPv6 addresses. That’s annoying since it’s 2011 and all, but if you have a Cisco router, I can show you how to create an IPv6 tunnel that will you have dual-stacked and on the IPv6 Internet in no time! This article assumes that you cannot use native IPv6 out to the Internet, and that you already have the router properly set up and in use in an IPv4 network.

My router is a 2621XM, I bought it for $150 on eBay. It has two FastEthernet ports. It was manufactured in 1999. So any model at least as recent as that should be able to handle this just fine. I do IPv4 NATing between the two FE ports so that the rest of my home network served by my AT&T U-Verse Residential Gateway stays separate from my lab network, but the lab still has to go through the U-Verse gateway to reach the Internet.

For this to work for me, I needed to configure my U-Verse Gateway to put my Cisco router in “DMZ+” mode, and allow the outside interface of my Cisco router to receive a DHCP address. This allows my U-Verse gateway to assign my router the same public IPv4 address as itself.

We’re going to utilize the free service at Hurricane Electric for this. Follow that link and sign up. It’s their “Tunnel Broker” service that you’re after. After a short quiz, they will give you your very own IPv6 tunnel and your very own IPv6 address space!

All you need to do now is configure your router. If you’re reading this site this is probably elementary to you, so you know what these shorthand commands mean:

Router#conf t
Router(config)#ipv6 unicast-routing
Router#copy run start

At this point you have enabled ipv6 routing globally. Next, create a tunnel on your router like this:

Router#conf t
interface Tunnel0
description Hurricane Electric IPv6 Tunnel Broker
no ip address
ipv6 enable
ipv6 address 2001:470:1f0e:5a4::2/64 (Use your side of the endpoint that Hurricane electric gave you!)
tunnel source (Your public IPv4 address)
tunnel destination (Hurricane Electric’s IPv4 endpoint for this tunnel)
tunnel mode ipv6ip
ipv6 route ::/0 Tunnel0

And you’re pretty much done! Configure your clients with an IPv6 address in that space, and you now have IPv6 connectivity all the way to the Internet. Google has a public DNS server at 2001:4860:4860::8888. Test out your tunnel by trying to ping that address. Remember that IPv6 and IPv4 are quite different. There is no NAT in IPv6. Internet communication is the way it was truly meant to be – end to end. That also means the need to protect yourself with firewalls will become more important than ever, since you can’t hide behind a NAT anymore!

Now you can surf the web with a “dual-stack,” meaning that you’re runnnig both IPv4 and IPv6 — and your IPv4 packets will take their normal route, while your IPv6 packets will be diverted through your new tunnel. Seamlessly. Pretty neat huh? Try to ping and see what happens! I guess that’ll have to do until ISPs catch up with IPv6 technology.

From here I could go on into configuring your own Windows-based DHCPv6 server, configuring your DNS server for IPv6 clients, etc… but that’s for another post. 🙂

Remote Desktop Services: RD Gateway

Hey there.  My name’s Ryan.  Yes, I know this is not my blog, but Ninjuh made the mistake gave me the honor of letting me contribute to his blog. He actually conducted a technical interview on me for my last job, and it was pretty clear from the onset that we were both really enthusiastic about technology and so became fast friends. And we’re also both passionate about carnitas and tomatillo sauce. But staying on track, this blog is about technology!

Remote Desktop Services is the new name for Terminal Services. When you hear “TS”, they probably mean “Terminal Services,” which is now known as “Remote Desktop Services.” You might hear someone say, “RDP to that server!” or “TS to that server!” . . . the terms are interchangable. RDP stands for Remote Desktop Protocol. Even on the most recent versions of Windows, you can go to the Start Menu -> Run… and type “mstsc,” which stands for Microsoft Terminal Services Client… but it’s all the same thing as Remote Desktop Services. The difference is that you can only have two users logged in “administratively” at once, but you can have a whole mess of users connected simultaneously to a Terminal Server/Remote Desktop Server that has the proper licenses. Just remember that RDS is the new hotness.

Well today I’m going to show you about a very neat feature of Windows 2008 R2 known as the Remote Desktop Gateway role service of Remote Desktop Services, formerly known as Terminal Services.
I’m not just talking about the same thing as the RD protocol on port 3389 that allows one computer to connect to another’s remote desktop. RD Gateway is a service that allows an administrator to create a gateway to the Internet that will allow Internet users a portal to your “internal” computers over SSL on port 443!

The RD protocol by itself is pretty damn secure really, but maybe you work in a big corporate environment. Maybe the network administrators of that big corporate environment have a really hard time swallowing the idea of opening port 3389 to the Internet. “Alright, fine,” you say. What if I only expose port 443 to the Internet? Secure Sockets Layer is PCI (Payment Card Industry) complant; it’s good enough for financial institutions and almost anyone. It’s secure enough that as far as we know, it’s as hack-proof-resistant as it gets. When I open port 3389 here at, (which is not open now that I have RDS to replace it,) I get anywhere up to thousands of logon failure audits a day – just kids around the world that have nothing better to do than try to log in to my remote desktop with random usernames like “joe,” “owner,” and “administrator.”

Keep trying, baby birds.

Alright, so let’s start with building a new server. A Windows 2008 R2 SP1 virtual server in Hyper-V. Go ahead and get that puppy fully updated. (Some of these images are click-to-enlarge. Some images have thumbnails while some do not.)


PRARLRDGW01. My naming scheme is thus: PR = Production. ARL = Arlington. RDGW01 = It’s the first RD Gateway server. Be careful not to let your server names get too long. (15 characters is the max for NetBIOS, with the 16th character being an archaic “extension” character. Add cluster node notations, etc., and I’ve seen large corporations reach that limit and run into problems, believe it or not.) Notice that this is a separate server than my primary web server. Maybe you could configure it to be the same as your regular web server. But I like to maintain a segregation of roles with my servers. I like to have a server doing as few things as possible. Plus my web server is running on the Web Edition of Windows Server, to which I couldn’t add the RDS role. 😛


Yeah so go ahead and add the Remote Desktop Services role to your server. You’ll notice that there are many different parts of RDS. But the part that we’re interested in for this tutorial is the RD Gateway. In my opinion it’s the first piece of the puzzle you need to concentrate on if you want to open a portal for Internet users to connect to your internal infrastructure via the Internet. So add that, and at this point you’ll notice that it requires some other bits and pieces be installed as dependencies. Most notably is IIS. There’s an interesting mechanism used by RD Gateway called RPC over HTTP, which is outside the scope of this article (which means I don’t fully understand it. . . But anyway, onward!)


Above it’s asking us about those dependencies we need to install. IIS, Network Policy and Access Services, and some RSAT tools for the role we’re about to install. And that RPC over HTTP Proxy thing. Whatever the hell that is! (Remote Procedure Call over HTTP. Remote Procedure Call is a network protocol that allows one machine to call for another remote machine to execute some code on its behest.) At this point during the installation, as pictured below, it’s going to ask us about a certificate.


If you’re doing this for a big company, this is the point where you need to actually go and buy a certificate from a “trusted 3rd party” cert company like Verisign. Which is such a sham, by the way. $700 for a basic certificate? Brings a new meaning to ‘buying someone’s trust!’ Or you could get one from your company’s Certificate Authority. That should satisfy internal users only. But you can also opt to just use a self-signed certificate, which is what I did. It’s free, but it also results in certificate errors being seen by the end-user, because no one trusts someone who has no one to vouch for them but themselves. That’s not acceptable if this deployment is for a company that needs to maintain a professional image. (I’m looking at you, companies with public websites that still don’t use proper certs.)


The picture above is simply the next step asking us if we want to create authorization policies now or later. Considering that RD Gateway is completely useless wihout those policies, I’m gonna’ go ahead and say we create them now.


The first thing we need to do (pictured above) is decide which Active Directory groups are going to have access to this system. Administrators was in there by default. I decided that just for good measure I would go ahead and create a custom “RDS Users” group and put people in there that I wanted to have remote access through this RD Gateway.


Alright so those users that we just defined in the last step, those are going in to a policy called an “RD Connection Access Policy.” Pretty self-explanatory, right? Now it’s just asking us to name that policy. It’s also important to note that here it’s asking us if we want them to be able to connect with a password, with a smart card, or be able to connect with either. Smart cards are becoming increasingly common in corporate environments as security requirements tighten, hacking attempts increase, and people keep writing their passwords down on sticky-notes and sticking them on their monitors or putting them under their mousepads.


The next step is your RD RAP, or RD Resource Access Policy. Now that you’ve already defined who can connect with your RD CAP, define what they can connect to with your RD RAP. If you had an important test or exam coming up that had anything to do with this stuff, it’d do you well to remember that you need at least one RD CAP and RD RAP each before RD Gateway can really be used at all.


The next step will ask you what role services you’d like to install for your new Network Policy Server. What? You didn’t mean to install the Network Policy Server? Well, surprise! It’s required for RD Gateway. It’s actually pretty cool if you give it a chance. You can do stuff like only allow people to connect to your network if they have the latest security patches installed, or if they have current antivirus enabled, or if they have their Windows Firewall enabled, or only allow certain people to connect to certain IP subnets, etc. But for now, let’s just leave all the settings at their defaults.


The above screenshot is simply the next step in the installation. It’s asking you to configure IIS. Remember, you need IIS for this. If you’re reading this tutorial, just take the defaults.


Oh my god it’s over! I mean . . . success!


The picture above is simply showing you my externally-facing firewall configuration. I’m only allowing two ports in – port 80 going to my web server, over which you are right now reading this webpage, and port 443, which is being directed to the new RD Gateway server. See? No port 3389 allowed through at all. Are you getting excited yet? I hope so. I spent a lot of damn time making all these screenshots.

(This is one of those thumbnailed images I told you about. Damn, if only I could give them a border or something to make them easy to identify…)

So I was thinking about certificates. You know . . . strategizin’. When it comes to certificates, when the hostname of the server who is making a claim about its identity doesn’t match the name with which the prospective client addressed them, well, that’s pretty much the number one error when it comes to certificates. So with this in mind, I went ahead and added a host record to my public DNS. prarlrdgw01.arl. That way when an Internet user attempts to address my RD Gateway server, they can do so by the name of And my RD Gateway server will agree that that is indeed its name. Hostname = prarlrdgw01. Subdomain = arl. Parent domain = Go ahead, try to ping it right now!


Alright so let’s switch gears now! Your RD Gateway server is pretty much done! Now we move on to your client configuration. To connect to an RD Gateway server, your workstation needs to be using RD Client 7.0 or greater. Which is like saying you need to be running Windows 7 or 2008 R2 or greater. So in the picture above, here I am on my PC out on the Internet, far away from my internal network. I’m configuring my client to get ready to connect to my RD Gateway back home. Start up the client by doing a Start -> Run… “mstsc”. Then hit the options dropdown and go to the advanced tab. Then hit that “Connect from Anywhere” Settings button. (Pictured above.)


Alright, now that I’ve configured my RD Gateway settings, I’m going to try to connect to the internal host PRARLPC01! Never mind the fact that I cannot resolve the name PRARLPC01 from the Internet! Throw caution to the wind! I’m so excited!



ARGH!!1 It didn’t work! All that preparation, for naught!

Alright, let’s compose ourselves. I don’t see any way around that message. I told the RDC client to ignore authentication errors and connect anyway, but it doesn’t matter. I don’t care that “it’s not safe!” Let me connect anyway!

Meh . . . maybe it’s for the best that it won’t let me connect anyway without proper authentication. Let’s go ahead and view the certificate with which we were presented when we tried to connect. It’s got the correct hostname on it from the perspective of both the client and the server, but see how it was both issued to and issued by the same server? That’s a self-signed certificate. And it’s worth a whole-lotta-nothin’. If you closely read the description of the certificate message pictured above, you will notice that it says it doesn’t trust the CA Root. The Certificate Authority is the entity that issued the certificate. Well . . . my RD Gateway server is no sort of authority on anything, but I know of someone who is. . .


So this little speed-bump gives me time to go ahead and make use of something I already had handy – An Enterprise Root CA. Now keep in mind that the next couple of steps are not completely necessary – I’m just doing it to exercise my already existing ECA. It should still be possible to proceed with a self-signed cert. To skip this part, just scroll down until you see the big !!!

An Enterprise CA is a server role; it is integrated with Active Directory and its purpose is to provide your “Enterprise” with certs, be it certs for smart-card login, or certs for EFS encryption, or certs for Network Device Enrollment, or certs for a formerly useless RD Gateway server. So what I’m doing in the picture above is, from my RD Gateway server, open up an MMC, and add the Certificates snap-in. Specify that you want to see Computer certificates for the local computer. Then right click on the Personal certificate store, and Request a New Certificate . . .


Now since you already have a properly configured Enterprise CA (uhmmm. . . that’s for a future tutorial I guess,) you will now get the dialog box pictured above. This is the sign that you as a client have properly detected your domain’s Certificate Authority and the enrollment policies that it has to offer you. So go with the flow. . .


And here, pictured above, it’s simply telling you that yes, because of the aforementioned awesomeness in the way you have set up your domain, that you are indeed eligible to enroll for your very own Computer certificate, courtesy of your friendly neighborhood Enterprise Certificate Authority!


Now on your RD Gateway server, check out your Personal Certificate Store, via the Certificates MMC snap-in. (Pictured above.) See how you now show two certificates? That first one is your crummy old good for nothing self-signed certificate that you made earlier. The next one as you can see was issued by your ECA, and should allow every client in your domain to implicitly trust you! Implicit trust is a hard thing to come by, both in life and in Remote Desktop Services.


Now go to RD Gateway Manager on your RD Gateway, either by Administive Tools on your Start Menu or in Server Manager, and right click on your server and go to properties. (Pictured above.) What you want to do is import your new certificate – the one issued by your ECA – for use by your RD Gateway. Instead of the self-signed one.

!!! (If you skipped the ECA part, resume here.)

Our final problem is that even now that we have a certificate issued by our Enterprise CA and should therefore be implicitly trusted by all our fellow domain members. . . well, our Enterprise CA doesn’t mean jack out on the Internet. Internet users still won’t trust us. Who the hell is that? Sounds like a scam to me. . .

So your last recourse is to, on the client from which you wish to connect to the RD Gateway, import the certificate of the issuer whom you want to trust – be it a self-signed cert, a CA-signed cert, or a third-party cert. . . into your workstation’s personal store. I suppose you could either see this as a hassle, or as an extra measure of security. But one way or the other, unless you’ve figured out some way to circumvent that RDC 7 requirement to trust the RD Gateway vis a vis certification. . . you’re going to need his certificate. You either need to import the self-signed certificate from the RD Gateway, or you need to import the certificate of the issuing CA, if the RD Gateway’s certificate was issued by a separate CA. If your RD Gateway was issued a certificate by another CA, and you import the certificate of the RD Gateway instead, the client connection attempt will let you know that “more information is needed before Windows can trust this computer.” Don’t ask me how I know.


The picture above is me exporting the certificate from my issuing CA. Go to Start -> Run… and type “mmc”. Add the Certificates Snap-In. Choose Computer account. Go to the Personal Certificate Store. Right click the one that was issued to and issued by your CA, and Export it. (My ECA is also a domain controller, so that’s why you see that other cert in there.)

Now you need to share this certificate with everyone that you want to be able to connect to your RD Gateway. You could do it manually by sharing a URL with the users that points to the certificate so that they could download it and import it themselves. You could assign it to all your users via Group Policy if this were some case of business-to-business federation. (AD Trust relationships are going out of fashion.) Or maybe you could come up with something else creative that I haven’t thought about yet. I’m thinking about providing a download link to
mine on my upcoming RD Web Access website. See, that’s the difference between self-signed certificates or your company’s Enterprise CA issued certificates, and “Trusted 3rd Party” certificates that you can buy online for hundreds of dollars. Those expensive 3rd party certificates from companies like Verisign are trusted automatically by almost everyone, whether they’re in your own domain or on the other side of the planet. . . and not in your domain.

So now you’re back on your client machine that is not on your internal network or in your domain. On this machine, you want to import the certificate of the issuing CA that issued the certificate to the RD Gateway server to which you want to connect. . .



You need to install this certificate in the “Trusted Root Certification Authorities” store. Don’t let Windows automatically select where to put it. There’s no telling where it will go. Best to specifiy it yourself.


I can’t really explain it any better than the above picture. From henceforth after installing this cert, you will trust any computer that was issued a cert by the issuing authority whose certificate you’re about to install. Also I figured I’d blur out that thumprint part. I don’t know if it matters or not. . . from what I understand, certificates are pretty difficult to forge. But blurring things out makes me feel more important.

And now, finally, here is the culmination of all this effort. Go back to your RDC client on your external machine and try to connect again. Remember to configure the RD Gateway settings in the advanced tab like we did before. . .


And magic! It dropped me right on to the desktop of one of my internal PCs, regardless of the fact that its name wasn’t even resolvable by my client! I am now on the remote desktop of PRARLPC01, via port 443 to my RD Gateway, which then turns around and contacts the internal machine with 3389. Port 443 is the only port exposed to the Internet, and my remote desktop connection is SSL encrypted. Pretty awesome, right?

That’s all I’ve got. Thanks for sticking it out through this really long tutorial. Hopefully it helps you. Next time, I think I’ll set up RD Web Access, so stay tuned!