Default Account Pictures via Active Directory

Alright, I need to post this so that I have it written down somewhere, because it was a little bit of a pain in the ass to get just right.

Do you administer a modern Windows domain? Are you tired of seeing the sunflower or the mannequin-like brown man as the account logo that appears whenever you log in to a computer? Sure you can customize it locally on your own workstation, but you still see those annoying defaults any time you connect to a remote server or log in to a new PC on which you haven't configured your profile.

  

Well here is how I've configured my domain so that all users get a new, customized logon logo.  The first thing to consider is you need a new, customized logo.  Maybe it's your company logo.  It needs to be accessible during logon to all users to which you want the new image to apply.

So first, I'll make a new image:


It's probably best to make it a bitmap (*.bmp) and 128x128 pixels.  You might be able to play around a little with those properties, but that's what the sunflower was so I'm playing it safe.

Now since I want everyone to be able to get at this image during logon, I'm going to put it on a network share.  In this case, the network share is a DFS share and namespace that is on both of my domain controllers for high-availability.  Very much like SYSVOL.

That's a lot of information in one screenshot there, but it's just me putting my 128x128 bitmap of my new logon image on a network share; somewhere where everybody in your domain can access it.

Next, it's time for some group policy work.  Log in to one of your domain controllers.  Fire up Group Policy Management Editor.  Now I went ahead and put this in my Default Domain Policy.  But maybe you want to be a little more scrupulous.  You could create an entirely new GPO for this, apply it only to certain users, etc.  But for my little test domain, the Default Domain GPO will be just fine.

The setting you want to edit is User Configuration -> Preferences -> Windows Settings -> Files.  You want to add a new file and make it look like just what I have here:


It's very important that you choose "Replace," as the other options like Create and Update will tempt you, but will ultimately only end in frustration as you wonder why the $@&# it isn't working.  What we're doing here is assigning every user that is affected by this GPO (which is basically everyone in the domain since it is the default domain GPO,) that they grab the source file from the network share, and replace their local %PROGRAMDATA%\Microsoft\User Account Pictures\user.bmp with it.  That is the local default logon picture for Vista and 2k8/R2 versions.  Shame on you if you're running older OSes anyway.

One last piece is that you could edit that GPO to disallow users from changing the logon picture to something else. That setting is at Computer Configuration -> Policies -> Administrative Templates -> Control Panel -> User Accounts -> Apply the default user logon picture to all users.  If you set that to Enabled, regular users will not be able to change the default user account picture that you have now set for them.

It's also worth noting that yes, you can store images in user account objects within the Active Directory database itself.  Each user account object has a thumbnailPhoto, thumbnailLogo, and jpegPhoto attribute in  the AD database.  You can store images here, and they will be replicated along with all the other database data, and as you would imagine, such activity would quickly bloat your database and complicate AD replication.  Also, these attributes are only used by certain applications such as Outlook 2010, Sharepoint, etc.  This will not affect the "user tile" or Windows logon image as we have done here.


(repadmin /syncall on your domain controller to replicate new changes to other DCs.  gpupdate on your workstation to pull the new changes down from the DC.)

Check out that new sexy default logon picture!  It will now show up by default wherever I login in the domain.

Tales from the Office Vol. 1

You know your department is trying to use up its funding before the end of the fiscal year when you start seeing things like deliveries of 70-inch monitors.

I got an email concerning a company KB article I wrote which contained the phrase: "Also, the Status of “Kickin’ rad” is not acceptable, please put a more acceptable status in there..."

I was just making sure somebody actually read those things...

Finally, McAfee sucks.

Remote Desktop Services Tutorial #2 (RD Web Access)

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

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 https://prarlrdgw01.arl.myotherpcisacloud.com/RDWeb. 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!

Remote Desktop Services Tutorial #1 (RD Gateway)

Remote Desktop Services is the new name for Terminal Services.  When you hear someone say "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 Client or Remote Desktop Protocol Client. The catch 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 proper 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, especially with the newest version with NLA (Network Level Authentication,) 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-resistant as it gets.

When I open port 3389 here at myotherpcisacloud.com, (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 all 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. :P


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. 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 IIS. There's an interesting mechanism used by RD Gateway called RPC over HTTP, which is really where the magic happens.


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.