Allow Logon Through Terminal Services vs. Remote Desktop Users group: Which and why?

I always end up forgetting which permissions I need to grant users and where to do so when setting up terminal services... so I go googling, and end up finding the answer eventually... but I figured it's about time I left a note for myself (and others!) about which permissions you need to grant users, where they are, and why.

For starters, this article does a great job of explaining:
http://blogs.technet.com/b/askperf/archive/2011/09/09/allow-logon-through-terminal-services-group-policy-and-remote-desktop-users-group.aspx

I'll do a quick summary of the contents, though, and borrow the images in case that site goes missing at some point. All credit goes to the original poster, of course. :P

First, there's the "Allow Logon Through Terminal Services" GPO, located under Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\. This policy is what controls granting access to the particular machine. When you assign this GPO to a particular machine and add a group to it, that group automatically gains rights to log on to this computer, access local resources, etc. By default, Administrators and Remote Desktop Users are assigned to this policy.

Second, there's the Remote Desktop Users group. This group, as you saw above, is already a member of the "Allow Logon Through Terminal Services" security setting on most servers by default (except for domain controllers, I believe the default domain controller policy overrides this setting allowing only Domain Admins... but I could be wrong here.). The other thing this group does is grant access to connect to the RDP-TCP service on the server. You can see/change which users and groups have access to the RDP-TCP listener by opening the Terminal Services Configuration snap in and checking the Security tab, as shown below:



Finally, here's a quick recap of the typical error messages you see, and what that generally means:

1) "To log on to this remote computer, you must have Terminal Server User Access permissions on this computer..." or "The Requested session access is denied": This error means that the user that tried to connect has been assigned to the GPO correctly for "Allow Logon Through Terminal Services", but the user is not a member of the Remote Desktop Users group, or otherwise does not have permissions to the RDP-TCP listener on that machine. Go check the Terminal Services Configuration snap in.

2) "To log on to this remote computer, you must be granted the Allow Logon Through Terminal Services right..." or "The connection was denied because the user account is not authorized for remote logon." This error is pretty strait forward... the user is not assigned to the "Allow Logon Through Terminal Services" GPO.

Assigning Trusted sites in IE via group policy preferences

Assigning sites to a user's trusted sites has always been a thorn in my side, mostly because the process for using group policies was such a pain... creating a blank profile, setting it up right, exporting it, blah blah... and to top it all off, assigning a policy prevented the user from adding any more sites to their trusted sites, making the policy settings more of a hinderance than a help.

Group policy preferences greatly enhances this process by 'adding' sites rather than enforcing only your selections. Here's a process I found off of a microsoft forum post:


1. First off create the registry entries manually, as shown below, on a reference machine. I've done this on the local machine where i need the keys to be added for all users. NOTE: The reference machine does not need to be where the keys have to be located.Manual Creation Steps:

a. launch regedit and go to: hkcu/software/microsoft/windows/currentversion/internet settings/zonemap/domains/

b.create a new key called microsoft.com. In the new key create a reg_dword(32) value called * and change the data to 2 hex.

c. repeat for any other domains the need to be trusted2. launch group policy management (again i did this from the machine where i need the keys but it is not required)

3. go to your GPO and select edit.

4. go to user preferences / windows settings / registry

5. right click registry / new / registry wizard

6. select local computer if you are on the computer where you created the reg entries and are running the GPO management gui. Otherwise choose another computer and select the reference machine from step 1.

7. the wizard will guide you through choosing the required entries, check off all required items. These entries are the ones created in step 1.

Location: hkcu/software/microsoft/windows/currentversion/internet settings/zonemap/domains//


8. Click Finish

9. You can then go back to this GPO preference and select its properties and utilize client side targeting if only certain AD groups need the values.

10. perform a replication to all DC's then a GP update /force on the machines in question; you will be asked to log out for the preferences to take. (or reboot)

SBS 2011 Remote Web Workplace "Login attempt failed" bug

Spent a few hours of my life that I never should have, figuring out this little gem. I had a freshly installed SBS 2011 server, with exchange mailboxes migrated and most of the migration wizard completed, when suddenly I noticed I could no longer use the remote web workplace to remote control any of my workstations or servers from the outside. I would get the login credentials box correctly identifying the server i was connecting to, but after entering my username and password it would come back indicating "The logon attempt failed." It worked just fine in tests earlier on, so something in the setup and migration wizard must have incorrectly tweaked something.

Turns out, it was an IIS configuration issue that appeared most likely after running the Network Preparation / Outlook Anywhere wizards. I opened IIS, expanded the default website, and inspected the authentication options for RPC and RPC with cert... both had only 'basic authentication' checked, which I was fairly certain would not work with Remote Desktop web access services. Enabling 'Windows Authentication' and performing an iisreset did the trick... but after a few minutes, it got set back to disabled! An event in the logs from "MSExchange RPC Over HTTP Autoconfig" source indicated that the settings for Outlook Anywhere had been updated, setting it back to Basic only!

The fix that eventually worked (and stuck) was to make the following change in the Exchange Management Shell:

Get-OutlookAnywhere | Set-OutlookAnywhere –IISAuthenticationMethods: Basic, ntlm

After making that change, it may not show up in IIS right away... wait a few minutes, and that same Autoconfig service will update IIS for you, this time adding both Basic and Windows authentication. Voila!

Recovering from 'Exclusive Access' rights when redirecting documents

One very useful, yet much hated, option when redirecting user documents is to "Grant user exclusive rights" to their redirected folders. If your users store sensitive or private information that not even administrators should be able to see in their folders, it's a great way to automate the process of users creating their own folders with locked down permissions upon initial logon. What happens when you NEED access to all those folders for a specific group, or for the admins? The Microsoft recommendation is to go through each folder and seize ownership, then re-apply the correct permissions... a tedious process to say the least. Well, there is a scripted way to do it that works much better (taken from http://mypkb.wordpress.com/2008/12/29/how-to-restore-administrators-access-to-redirected-my-documents-folder/):

First, you'll want to make sure that the offending GPO is turned off. It's an option under the folder redirection GPO (User configuration / Policies / Windows Settings / Folder Redirection) that needs to be unchecked, otherwise any new users will be set up with exclusive rights still.

Next, you'll need PSExec from SysInternals (http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx) and PowerShell installed on the server hosting the shares. Log on to your file server as the LOCAL (not domain!) Administrator. Now, create the following powershell script, and be sure to edit the $StartingDir attirbute to point to the parent folder that contains all the users' folders:

#ChangePermissions.ps1
# CACLS rights are usually
# F = FullControl
# C = Change
# R = Readonly
# W = Write

$StartingDir= "C:\Users"

$Principal="Administrators"

$Permission="F"

$Verify=Read-Host `n "You are about to change permissions on all" `
"files starting at"$StartingDir.ToUpper() `n "for security"`
"principal"$Principal.ToUpper() `
"with new right of"$Permission.ToUpper()"."`n `
"Do you want to continue? [Y,N]"

if ($Verify -eq "Y") {

foreach ($file in $(Get-ChildItem $StartingDir -recurse)) {
#display filename and old permissions
write-Host -foregroundcolor Yellow $file.FullName
#uncomment if you want to see old permissions
#CACLS $file.FullName

#ADD new permission with CACLS
CACLS $file.FullName /E /P "${Principal}:${Permission}" >$NULL

#display new permissions
Write-Host -foregroundcolor Green "New Permissions"
CACLS $file.FullName
}
}

Save that .ps1 file to the C: drive or somewhere convenient, then open the command prompt as an administrator (right click, run as), and execute the following command:

psexec -s -i powershell -noexit "& 'C:\ChangePermissions.ps1'"

This will execute the powershell script as the local 'SYSTEM' account, which still has access to the 'exclusive' user directories, thus allowing you to modify permissions without having to seize control! Now that the LOCAL 'Administrators' group has permission to the folders, you can browse to the folders and modify permissions as you see fit. My recommendation would be to set the permissions you want on the parent folder, then just check the box for 'allow permissions to be inherited from the parent folder' so you do not have to manually add domain admins to each user folder.

Setting up PCNS 3.0.0 for ESXi 4.1 update 1

Note: An updated version of these instructions for ESXi 5.0 and PCNS 3.0.1 is available in a new post here: http://tsbraindump.blogspot.com/2012/08/installing-and-configuring-apc.html

I've done this setup 3 times now, and every time I end up having to resort to trolling the internet for instructions, so I figured it's about time I write down my own. Note these are from personal experience, contacting support, etc etc.

1) Download stuff. There's a bunch of it!
a) Download PCNS 3.0.0 from the APC website. It's free now, it just requires an apc.com login.
b) While you are there, grab the latest firmware for the APC card you are using. Make sure you know the kind of network management card you have, as the older ones are not able to use the latest firmware.
c) Download the latest VMware vMA from the VMware.com website under 'tools'. As of this writing, it's 4.1 released in 2010.
d) Grab the free version of Veeam fastscp... it makes loading the APC installer on the vMA a snap.

2) Install the latest network management card firmware first. It may take several shots at it... for some reason it likes to fail, but doing it over and over usually gets it going. Don't ask why.

3) Create one vMA virtual machine FOR EACH HOST by extracting that zip file you downloaded and then launching the vSphere client and going to File -> Deploy OVF Template. It will guide you through what's required, but you basically need a 5GB volume (I usually make the volume 10GB for snapshot space), 1 processor, and a gig or so of ram. Note that I said "for each host". I spoke to APC support, and they admitted (finally) that the vifp 'fastpass' stuff does not work. My personal experiences confirm this. For some reason it only shuts down the first host on it's list!

4) Open the console of the vMA and follow the initial setup instructions. I recommend assigning a static IP as well as a real hostname to the vMA for use later. For the hostname, specify a full domain name such as VMA.domain.local.

5) Install Veeam FastSCP, then open it. Click "Add Server" and add the vMA server as a "Linux Server". Be sure to use the vi-admin username and password you specified while setting up the vMA. Uncheck the box to "Elevate account to root" as we do not have root access - it's been disabled.

6) In FastSCP, browse to the pcns300ESXi.tar.gz file you downloaded earler and right click / copy it. Note that you have to right click / copy in FastSCP, not in windows explorer... FastSCP does not have windows clipboard access built in. Once copied, expand your vMA in FastSCP, browse to the tmp folder, and paste it in the root of tmp. You can close FastSCP now.

7) Back in the vMA console, browse to the tmp directory and run "gunzip pcns300ESXi.tar.gz", then run "tar -xf pcns300ESXi.tar" to extract the file. Browse into the ESXi folder that is created, and run "sudo ./install_en.sh" to start the installation of pcns 3.0.0. You will likely get prompted with a warning (read it, it's funny) and need to enter your password. After that, installation starts. Continue with all the defaults. When you get to the part about entering an IP, just press "q" to skip it.

8) Make sure you get the message about Installation has completed, and the note about how to access it - this means installation was successful. Now, you need to add your ESXi servers to the 'fast pass' access via the following command: "sudo vifp addserver". You will be asked to enter the password for your host, so vMA will have it on file.

9) Now, we need to configure PCNS. Open a web browser and go to https://:6547 and follow the configuration wizard. The only step worth menitoning is that you should NOT check the box for "Turn off the UPS after shutdown finishes." If you check it, there's a good chance the UPS will turn off while your hosts are still shutting down. The caveat to leaving this unchecked is that your ESXi servers most likely will not turn back on if power is restored before the UPS battery loses all of it's charge... you'll have to use iLO or DRAC to get in and turn your hosts on instead.

10) Next, you will want to configure shutdown events. Once the PCNS wizard finishes it forwards you to the PCNS configuration page. Click on "Configure Events" and configure some of the important events like "UPS: On Battery" and "Input Power: Restored". You'll most likely want to notify users for most of the events. Don't forget to check the box for "Shut Down System" next to "UPS: On Battery" and set it to go off after a reasonable amount of time on battery (this depends on how much runtime your battery has, but I usually set mine for 5 minutes. If the power is off for 5 minutes, it's most likely going to be off an awful lot longer.)

11) Also, you'll want to check the "Connected Servers" tab on the left under "UPS information" to make sure your vMA IP address is listed. If not, you'll want to add it as a client on your UPS's network management card's web page.

12) Finally, in the vSphere client, make sure all of your ESXi hosts have their "Virtual Machine Startup / Shutdown" options configured and they are set to "Enabled", otherwise your guests are likely to just be turned off rather than shut down!

13 Repeat these steps for each host in your cluster. Yes, you need one VMA per host! Don't believe me? Fine. Try it yourself. Or call APC. You'll see.

That should get the system going! You can test it by, well, pulling the plug! If that's too scary for you, you can also configure the shutdown option for "PowerChute cannot communicate with the NMC", then pull the network cable from the network management card. If your hosts and guests shut down correctly, all is well!

Setting LUN Policy and PSP in ESXi 4.1

For customers with many LUNs, it can be a serious pain to create, modify, and maintain all the multipathing settings in VMware ESXi... I have a client with four active iSCSI adapters on each host, and four active iSCSI frontend ports on their Compellent SAN, which means a delightful 16 paths per LUN. Couple that with 2-3 LUNs per guest (raw device mappings), and 15 or so guests... that's a lot of clicking.

This is where VMware's vCLI is a godsend... you can script all of those monotonous clicks. For example, here's a pair of scripts I used to convert all of their Path Selection Policies and default PSP's to Round Robin.

1) Download and install vCLI
2) type "connect-viserver hostname" (where hostname is the name of the ESX host you want to make the changes on)
3) type "get-scsilun -vmhost (get-vmhost hostname) -luntype disk | set-scsilun -multipathpolicy "roundrobin""
4) Open an SSH prompt to the ESX host in question (you may need to enable SSH access in your hosts Configuration > Security Profile in vSphere).
5) In the SSH prompt, type "esxcli nmp satp setdefaultpsp --psp VMW_PSP_RR --satp VMW_SATP_DEFAULT_AA

NOTE: The --satp type may vary depending on what SAN you use... you can check what your SATP currently is by clicking "manage paths" of any one of your LUNs in vSphere... under the path selection type it displays it as "storage array type".

That's it... now all the LUNs on the host should be round robin, and all future volumes should default to round robin as well!

Update:

For ESXi 5, the SSH command syntax has changed slightly. You'll want to type the following from the console of your ESXi 5 server:

esxcli storage nmp satp set --default-psp VMW_PSP_RR --satp VMW_SATP_DEFAULT_AA
Also, the part about vCLI is no longer necessary! Once you switch the default path policy with he above command, you can just reboot the host and it should apply the policy to all existing volumes. Thanks, VMware!

Exchange 2010 Edge Role + 2 NIC cards + DNS issues

I am trying out a few technologies that are new to me for one of our clients, namely Exchange 2010 with the Edge role on a DMZ server, as well as installing Threat Management Gateway on the Edge server... good times! I am sure there will be several posts on TMG coming soon... I can feel it now...

Anyway, I ran into a DNS problem with my fresh Exchange 2010 install that took a little bit of doing to figure out what was going on. The basic layout of the environment is that they have a single Exchange 2010 server on their LAN with the CAS/HUB/MBX roles installed, and a single EDGE role on a DMZ server that is on the domain. This Edge server has two NIC cards... one for the inside network so it can talk to the domain and do windows authentication, and one for the outside network so that it can receive mail and publish the Exchange web interface.

Shortly after installation, mail started queuing up on my edge server. Taking immediate advantage of the tools in front of me, I used the Queue viewer and noticed a few DNS warnings that certain domains could not be resolved. Thinking I was smart, I proceeded to put in hosts entries on the Edge server... nope, didn't solve it. I then thought that perhaps it was using the external interface's DNS server to try and resolve internal server names... so I took the DNS servers away from the external NIC card... still no luck.

Then, I stumbled upon a setting that suddenly cleared it all up: on the edge server, if you open up the Exchange management console, right click on the Edge server in the middle pane, and go to properties, there is a tab for 'External DNS lookups.' I set this to the Inside NIC card, and bam, mail started flowing.