Colleague: Windows Server, Where’s Windows Security gone?
Me: Eh?
Colleague: Windows Security!
Me: What are you trying to do?
Colleague: I want to change my password and I can’t send a Ctrl+Alt+Delete to the remote server.
Well I know that pressing Crtl+Alt+Delete would let you change your password like so;
I wasn’t aware that in Server 2008 and earlier if you were connected via RDP you got a ‘Windows Security’ option that lets you do the same, like so;
This is because if you press Ctrl+Alt+Delete it will execute on YOUR machine not the remote one. But this option is not included in Windows 2012 any more.
Solution
Well you can just normally use Ctrl+Alt+END while in an RDP session. But like me, my colleague was using a Mac and we don’t have an END key!
Mac OSX Sent a Ctrl+Alt+END Sequence
If your RDP connected from OSX then use Ctrl+Alt+Fn+Backspace
If your RDP connected using a Mac Keyboard, or from a VM session on your Mac (i.e. from a VMware Fusion Windows Machine), then use Ctrl+Alt+Fn+Right-Arrow.
Other Solution
From within the RDP session, launch the on-screen keyboard, (Start > Run > osk). Then Press Ctrl+Alt on your physical keyboard, and click the delete key on the on-screen keyboard with your mouse cursor like so;
BETTER Solution
Within the RDP session open powershell and run the following command;
Note: If you have a bunch of RDP servers you wanted to roll this out to, you can set it up on your administrative account, capture your start menu to an XML file, and then distribute that start menu to all your users via group policy, (not available with server 2012 or earlier).
Related Articles, References, Credits, or External Links
Remotely connecting to Windows is easy we’ve had RDP since Windows NT4, (yes I’m that old). But what if you want to remote connect to a mac? Well that has ‘Screen Sharing’ built in, (which it pretty much the same, but it uses VNC).
If you’re unfamiliar with VNC, (Virtual Network Computing,) you can install it on both Windows and Linux. Normally you need a client, (to connect with) and a server, (to connect to). VNC server is built into your Mac, so you just need to switch it on.
Note: To access though a firewall you will need to have TCP port 5900 open/forwarded to the mac.
Solution
Apple Symbol > System Prefernces > Sharing.
Tick: ‘Screen Sharing‘ > Computer Settings > Tick VNC viewers may control screen with password > Enter a password > OK.
On a remote machine download a VNC client (there are a lot to choose from!) > Point it to the IP address of your mac > Enter the password you set, (above).
And you are connected.
Related Articles, References, Credits, or External Links
I’ve got a job coming up to deploy some Duo two factor authentication into a clients RDS farm. To make things a bit easier for them I needed to migrate their RD Connection Broker. They had their Connection Broker, Gateway, and Web roles on one server, (which is not unusual, or incorrect). It turned out, that moving the Connection Broker, was going to be a major task, and it would be a lot easier to move the other two roles.
Solution
Note: Before deploying make sure you have the certificate ready to import (in .PFX format with a known password). If you are confused export the one from the old server. If you’re still confused use the search button above, I’ve written that procedure up before.
Moving the Gateway and Web roles is actually pretty simple to do, the process is, add the server to the RDS farm, ddd the Role, migrate the IIS settings. You can then repoint your firewall rules to the new server and remove the roles form the old one.
Build your new server, update it and join it to the domain.
Add the new server into the RDS deployment, (on one of the RDS farm members).
You can (from one to the other servers in the RDS farm) now deploy the new role, I’m going to deploy RD Web Access first.
Search for, select, then add the new server > Next.
Add
The new role will be deployed, (time for a coffee?).
Select ‘Configure Certificate’.
Your newly added role will say ‘Error’ > Select it > ‘Select existing certificate’.
Browse to the certificate > Supply the password > Tick ‘Allow the certificate to be added to the Trusted Root……’ option > OK.
When the display changes to ‘Success’ > Apply > OK.
Now you can add the other RDS Server(s) into the Server Manager console on the ‘new’ RDS server.
Now to ‘migrate’ any custom IIS settings, download the web Deploy Tool, either directly fromMicrosoft,
Or you can deploy from the Web Platform Installer.
Then to migrate all the IIS settings issue the following commands;
[box]CD “C:\Program Files (x86)\IIS\Microsoft Web Deploy V3”
Why is it so difficult to remove Administrative tools! The one folder you might not want your users having access to is on everyones start menu by default? I’ve seen posts saying to change the permissions so users can’t run the snap-in’s in that folder, and other posts that suggest removing it from the ‘all users’ profile, and yet more posts that say remove it in preferences with a post Vista start menu. NONE OF THAT WORKED?
This solution is for Windows Server 2012 R2, if you’re running an earlier version then I invite you to post a decent solution a the bottom of the page.
What I did was create a Custom Start screen, then exported that to XML, then configured all my users to use that start screen.
Solution
Log in as an administrator, and tailor the start screen to how you would like if for your users.
Then open a PowerShell session and export the settings to an XML file. I’ve already setup a network share on the RDS server itself to store the XML file in, (grant users ‘read‘ rights to the share).
[box]
Export-StartLayout -Path \\{server-name}\{share=name}\{file-name.xml} -As xml
[/box]
Now on the GPO linked to your RDS Server(s) add the following;
[box]
Computer Configuration > Administrative Templates > Start Menu and Taskbar > Start Screen Layout
[/box]
Enable the policy, and point it to the file you exported above. Then either force a policy refresh or wait a while for the new policy to take effect.
Related Articles, References, Credits, or External Links
Getting this article to completion has been a bit of a journey! This is the final post that will stitch together all the others I’ve posted over the last couple of weeks, that will enable you to publish your RemoteApps with ‘Remote Desktop Web Access’, and have that service presented securely from your DMZ. I’ll be using Active Directory Federation Services, (you don’t have to, but it’s more secure than simply using ‘pass-though’ security).
Solution
Prerequisites
Topology: Simply getting your ‘ducks in a row’ will take a lot longer than actually deploying the service. Here is the topology that I’m going to deploy;
Firewall Rules: You will see I’ve labelled all the Certificate/CRL rules as optional, this is because you would only need them if you were using self signed certificates. In this example that’s what I am doing, this means that all my remote clients need the root certificate installing on them, so for production I suggest you purchase a publicly signed wildcard certificate for simplicity.
DNS Requirements: For your internal domain and the DMZ it’s simple enough but your external clients will need to be able to resolve your public URL (and the URL of your CRL is used).
Certificate Services (Optional): If you want to deploy self signed wildcard certificates you will need a PKI environment and a published CRL. See the following article;
MAKE SURE: You have ran Windows updates on the WAP server, there are a number of bugs that have been fixed, ensure you have at least KB2975719, and in addition you need to have KB2983037 Hotfix installed.
Step 1: Add A Relying Trust To Active Directory Federation Services For Web Application Proxy
On your ADFS Server > Administrative Tools > AD FS Management > AD FS > Trust Relationships > Relying Party Trusts > Add Relying Party Trust.
Next.
Enter data about relying party trust manually > Next.
Give the trust a name > Next.
AD FS Profile > Next.
Next.
Next.
As an identifier, add in the UEL to access Remote Desktop Web Access > Next.
I do not want to configure multi-factor authentication settings for this relying party trust at this time > Next.
Permit all users to use this relying party > Next.
Next.
Untick “Open Edit Claim Rules dialog for this relying party trust when the wizard closes’ > Close.
You should see your relying part trust listed, take note of its name.
Step 2: Configure Web Application Proxy To Publish Remote Desktop Web Access
On the WAP Server > Administrative Tools > Remote Access Management > Select the Server > Publish.
Next.
Select ‘Active Directory Federation Services (AD FS) > Next.
Note: As mentioned above, you can choose ‘pass-through’, then author authentication is done on the internal RD Web Access server (which is less secure).
Select the relying trust you created above > Next. (If it’s not there check https is open, and you can resolve the AD FS service name) > Next.
Give the publishing rule a name, and enter the URL the service will be published on, (this is usually the same inside and outside but does not have to be) > Select your wildcard certificate > Next.
Publish.
Close
In PowerShell execute the following command;
[box]
Get-WebApplicationProxyApplication -Name “SmoggyNinja Remote Desktop Web Access” | Set-WebApplicationProxyApplication -DisableHttp
If Like me you haver to open multiple RDP sessions to lots of different clients, who all have differend domain names and passwords then the move to Vista can be a shock to the system, as far as RDP goes anyway. If you want to bend the version of RDP shipped with vista to behave like the old one did in XP you will need to the following.
Solution
1. Locate your default.rdp file (it’s usually in my documents).
2. Now open this file using notepad. Start > run > notepad > File Open > Change the file type from txt to “All files” > navigate to default.rdp and open it.
3. Paste the following two lines onto the END
EnableCredSSPSupport:i:0 prompt for credentials:i:0
4. Then Start > Run mstsc {enter} > Options > Advanced > Change server authentication to “Do Not attempt authentication”
* Pre v 6.00
Related Articles, References, Credits, or External Links
If you didn’t already know the Remote Desktop Protocol Port is TCP 3389, that fine but what if you want to change it to something else? That begs another question, Why?
Well some people like to change the port to something else, so that different ports are open in the even of a nasty type performing a port scan on your machine/firewall, even the most clueless script kiddies know that if they see TCP 3389 open then RDP is probably going to be on the other end of it. Or you might want to have all you servers available to the internet via RDP (people do) but you can only port forward TCP 3389 to one internal IP address. If you change the ports for each server then you only need to forward one port to one server.
Solution
Note: This works on Windows 2000/2003/2008/XP/Vista/Windows 7
1. On the machine in question Click Start > Run (or type in the Start Search) > Regedit {enter}.
2. The Registry Editor will open.
3. Navigate to HKEY_LOCAL_MACHINESystemCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp
4. In the right hand window locate PortNumber.
5. You will need to select Decimal, you will see by default its 3389 change it to something else (I suggest a number above 1024). In this case Ill use 3390.
6. Make sure that RDP is actually enabled on the machine in question. (Note: If this machine has a firewall enabled it will block the new port either enable that port or disable the local firewall)/
7. To connect to this machine from another one, use the same remote desktop client, Click Start > Run > MSTSC {enter} and the the target computers name or IP address then a colon then the new port number.
Related Articles, References, Credits, or External Links
Server 2012/2008 R2 unlike their predecessors, comes with the multiple remote desktop session restriction enabled. If you are only connecting to a server for remote administration purposes that can get a bit annoying, especially if you have a generic administrative account that multiple techs are using, and you keep kicking each other off the server.
Just as with earlier versions of Windows server you CAN have two RDP sessions at any one time, the restriction is one logon for one account. Thankfully you can disable the restriction and there are a number of ways to do so.
Solution
Server 2008 R2 Option 1: Enable Multiple RDP sessions from TSCONFIG
Note: tsconfig.msc does not work on Windows Server 2012
1. On the server, click Start and in the search/run box type tsconfig.msc{enter}. Locate “Restrict each user to a single session” Right click > Properties.
2. Remove the tick from “Restrict each user to a single session” > Apply > OK.
Server 2012 and 2008 R2 Option 2: Enable Multiple RDP sessions via the registry
1. Start > in the search/run box type regedit {enter} > Navigate to:
[box] HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal Server [/box]
Locate the fSingleSessionPerUser value > Set it to 0 (Multiple sessions allowed), or 1 (Multiple sessions NOT allowed).
Server 2012 and 2008 R2 Option 3: Enable Multiple RDP sessions via Local Policy
1. Start > in the search/run box type gpedit.msc {enter}.
If you have Windows (Professional, Enterprise or ultimate) you can already connect to it remotely using RDP. Unlike Windows Server 2008/2003/2000 which can have two concurrent RDP connections for remote administration, Windows client operating systems can only have one. If someone is logged into the machine and you connect in, it simply kicks them out to the login page.
This was never a problem for me until I set up a tiny Acer Revo PC behind my TV to use as a media server. If anyone was at home using the media server and I remotely connected to it (I do this quite often to check client VPN’s and to check websites are up and firewalls I’m working on are configured correctly). The TV screen would fill with the Windows 7 Login screen.
Solution
To get round this problem you need to “Patch” a particular windows file called Termsrv.dll. Thankfully over at deepxw they have done the hard work for you, and created an installer that backs up your termsrv.dll file, then patches it.
1. Download the patch (UniversalTermsrvPatch_2) and extract it to your desktop.
2. Locate the installer for either x32 (x86) or x64 bit versions of Windows depending on which you have. If you’re unsure click here. Click “Patch” and it should say that it was successful.
3. Reboot the client machine.
Should you wish to revert back again;
Simply re-run the installer agin and select “Restore”. Then reboot.
Related Articles, References, Credits, or External Links
