Pages

Thursday, August 26, 2010

COPY TO Button Not Available in Windows Server 2008 R2

I had someone ask me today why the Copy To button no longer worked in Windows Server 2008 R2. He was trying to use it to make a customized mandatory profile for use with Remote Desktop Services, but the button was greyed out.

Just so happned I was reviewing Ch5 in our upcoming Microsoft Windows Server 2008 R2 Remote Desktop Services Resource Kit. Chapter 5 is our profiles chapter so the timing was perfect to post this answer:

Short story is, Copy To on a user profile has never actually been supported. For many reasons. Because of this, In 2008 R2 Microsoft did away with the functionality.

Copying a user profile over another could lead to problems if the copied profile had been used at all, because the profile being copied would be “tattooed” with inappropriate settings and naming, such as the following:

• A list of that user’s frequently run programs.

• The user’s documents folders will be incorrectly called Administrator’s Documents.

• The user may have access to Administrative Tools (this is incorrect for regular users).

• Windows 7 libraries will be broken.


Now the only profile you can copy is the default profile, which is not tatooed.

If you must make a customized mandatory profile, then you have to overwrite the default profile with another profile by running sysprep with an answer file that tells it to overwrite the default profile with the profile of the user that is logged in that runs sysprep. This is described here:http://support.microsoft.com/kb/973289

Here are the steps:

1. Log on as an administrator and customize the profile as needed. This is the profile that will be copied over the default user profile.

2. Create an Unattend.xml file and add a line of code to it to tell it to copy the profile of the user logged on over the default profile when the system reboots. The line you add is




The unattend file should look like this for 64 bit:


3. Save this Unattend.xml file to : C:/Windows/System32/Sysprep.

4. Once you have the Unattend.xml file in place, open a command prompt and type the following command:

sysprep.exe /oobe /reboot /generalize /unattend:unattend.xml

This will copy the user profile over the default user profile, with which you can then use the Copy To button.

But be warned, sysprepping a production machine will do things like:

• The sysprep command resets the computer SID as well as eliminating system-specific data like the computer name and the domain affiliation.

• It can also remove unique hardware drivers and can reset the Windows activation key.

If you are using VMs, then one workaround is to take a snapshot of the VM before sysprepping. After you are done running sysprep, rebooting, and copying the default profile to another location, apply the snapshot and the VM will be rolled back to its prior state.

People are circumventing this and posting their workarounds, such as using windows enabler to turn on the Copy To button and doing things the old way, but again this is unsupported.

You can also stand up a 2008 VM and then get a profile using the win2k8 server. Again, not supported.

Really the best way to do this is to NOT customize the mandatory profile but use the default profile as it is, and layer in your changes via GPO and GPP and scripting. That way you never have to deal with a customized mandatory profile.

More reading for you: http://blogs.technet.com/b/deploymentguys/archive/2009/10/29/configuring-default-user-settings-full-update-for-windows-7-and-windows-server-2008-r2.aspx

Sunday, August 22, 2010

An authentication error has occurred. The specified target is unknown or unreachable. NLA Error, XP SP3

This is really annoying and it took me a little while to find the fix, so I am blogging about this in hopes that others waste less time!

I have a 2008 R2 RD Session Host server farm. IT is set to accept only connections from NLA clients.
Connecting from any Win7 machine works great.

Then I tried to connect via a client running XP SP3, running RDC 6.1 (supports NLA) with CredSSP enabled.

I got the following error: An authentication error has occurred. The specified target is unknown or unreachable.


If I turn off requiring NLA on the farm servers, I can connect.
Next, I added RDC 7.0 and tried again. I get the same error. 
I tried from more XP clients, with the same setup and I get some that get in and some that give the error.  VERY CONFUSING.

Turns out,  there is a hotfix out there that fixes this:
I added: http://support.microsoft.com/kb/953760, and rebooted.   
Now it works.

What I find interesting is that the hotfix does not specifically lay out this exact error result.ARGH.If it had I would have found it SO much faster.

Note: WebSSO will still not work unless you have RDC 7.0 on your XP client - RDC 7.0 is a requirement for WebSSO.  

Tuesday, August 17, 2010

Minimum Certificate Requirements for Typical RDS implementation

I see this question a lot on the Microsoft RDS forum:  What certificates do I need to purchase in order to sucessfully implement a typical RDS environment with farms, and RD Web Access and RD Gateway?

Personally, I like to use separate certs for all needs so that the names on the certs all say what these services represent. 

This is my optimal setup:
  • 1 cert per farm name (farm1.ash.local, farm2.ash.local, etc)
  • 1 cert for rd gateway (rdgateway.ilove2ski.net)
  • 1 signing cert (sign.ilove2ski.net)
  • 1 web cert (SAN cert if no hairpin turn in the firewall) (rdweb.ash.local and rdweb.ilove2ski.net)
And really, certs are like 30 bucks each these days. So it’s not a huge expense.  Still for small businesses, it might still be an expense they wish to forgo. 

So, to set up RD Web Access, RD Connection Broker, RD Session Host server farms and RD Gateway with the least amount of certs: 


Get one cert for each farm name. (reason: you can't use SAN certs for server auth):
  • farm_1.domain.local
  • farm_2.domain.local
  • farm_n.domain.local
Install the pertaining cert to each appropriate farm member (make sure private key is included on each cert on each server). 


The cert you SIGN your remoteapps with needs to be the SAME on EACH farm member in ALL farms (so websso works across farms). 

Get a SAN with to cover all RDWEB names and RD Gateway names and RemoteApp signing:   
  •  rdweb.domain.local (if you use an internal URL), rdweb.domain.com, rdgateway.domain.com, sign.domain.com 

Install it to RDWEB, RD Gateway and on ALL farm servers in every farm.  Also install it on RD Connection Broker server.  

Configure it as a signing cert in RemoteApp Manager on ALL farm members and also in RD Connection Broker.  (Note, that this cert is only for signing on the farm servers...you already have a farm cert for server auth)

Configure it as the RD Gateway server cert in RD Gateway Properties.   

Reboot all servers and test.
This works for me. :)

Other cert info: