Home / server / Questions / 541870
Accepted
Warren P
Asked: 2013-09-27 05:43:32 +0800 CST

Can Remote Desktop Services be deployed and administered by PowerShell alone, without a Domain in WIndows Server 2012 and 2012 R2?

  • 772

Windows Server 2008 R2 allowed deployment of Terminal Server (Remote Desktop Services) without a domain, and without any insistence on domains. This was very useful, especially for standalone virtual or cloud deployments of a server that is managed remotely for a remote client who has no need or desire for any ActiveDirectory or Domain features.

This has become steadily more and more difficult as Microsoft restricts its technologies further and further in each Windows release. With Windows Server 2012, configuring licensing for Remote Desktop Services, is more difficult when not on a domain, but possible still. With Windows Server 2012 R2 (at least in the preview) the barriers are now severe:

  1. The Add/Remove Roles and Features wizard in Windows Server 2012 R2 has a special RDS deployment mode that has a rule that says if you aren't on a domain you can't deploy. It tells you to create or join a domain first. This of course comes in direct conflict with the fact that an Active Directory domain controller should not be the same machine as a terminal server machine. So Microsoft's technology is not such much a Cloud Operating System as a Cluster of Unwanted Nodes, needed to support the one machine I actually WANT to deploy. This is gross, and so I am trying to find a workaround.

  2. However if you skip that wizard and just go check the checkboxes in the main Roles/Features wizard, you can deploy the features, but the UI is not there to configure them, and when you go back to the RDS configuration page on the roles wizard, you get a message saying you can not administer your Remote Desktop Services system when you are logged in as a Local-Computer Administrator, because although you have all admin priveleges you could have (in your workgroup based system), the RDS configuration UI will not accept those credentials and let you continue.

My question in brief is, can I still somehow, obtain the following end result:

  • I need to allow 10-20 users per system to have an RDS (TS) session.
  • I do not need any of the fancy pants RDS options, unless Microsoft somehow depends on those features being present. I believe I need the "RDS Session Host" as this is the guts of "Terminal Server". Microsoft says it is "full Windows desktop for Remote Desktop Services client.
  • I need to configure licensing so that the Grace Period does not expire leaving my RDS non functional, so this probably means I need a way to configure TS CALs.

If all of the above could technically be done with the judicious use of the PowerShell, I am prepared to even consider developing all the PowerShell scripts I would need to do the above. I'm not asking someone to write that for me. What I'm asking is, does anyone know if there is a technical impediment to what I want to do above, other than the deliberate crippling of the 2012 R2 UI for Workgroup users? Would the underlying technologies all still work if I manipulate and control them from a PowerShell script?

Obviously a 1 word Yes or No answer isn't that useful to anyone, so the question is really, yes or no, and why? In the case the answer is Yes, then how.

powershell

3 Answers

  1. Best Answer

    I've found myself in the same scenario as you. Deploying Remote Desktop on a standalone Server 2012 box is quite hard, because the guys at Microsoft don't let you run this on a domain-less network and if you do, you can't manage all the settings.

    So, you can install a workgroup-based-box and get the Remote Desktop roles working on it. We need also to install Remote Desktop Licensing features on the same machine. But, once at this point, even if you have proper RDS CALs installed on the server, when the user logs in, receives the message that the trial period is on.

    I've finally managed to get it working, at least something like the good-old Terminal Services we used to know. That's working for me on two production machines of small clients who need RDS but can't afford having two servers on their network.

    Here we go:

    1. Install the Remote Desktop Licensing and the Remote Desktop Session Host role services using the following steps:

      • Open Server Manager
      • Click on Manage and select Add Roles and Features
      • Select Role-based or Feature-based installation
      • Under Remote Desktop Services, choose Remote Desktop Licensing and Remote Desktop Session Host role services.
      • Proceed with installation

    2. Add the License Server to Terminal Server License Servers group and restart the Remote Desktop service (you can use licmgr.exe)

    3. Add the licenses to the license server.

    4. Configure the Remote Desktop Session Host role with to use the local Remote Desktop Licensing server. Follow these steps:

      • Open PowerShell as administrator
      • Type the following command on the PS prompt and press Enter:

    $obj = gwmi -namespace "Root/CIMV2/TerminalServices" Win32_TerminalServiceSetting

    Run the following command to set the licensing mode (Note: Value = 2 for Per device, Value = 4 for Per User, we use per-user)

    $obj.ChangeMode(4)

    Run the following command to replace the machine name with License Server (mylicenseserver is the name of your server):

    $obj.SetSpecifiedLicenseServerList("mylicenseserver")

    Run the following command to verify the settings that are configured using above mentioned steps:

    $obj.GetSpecifiedLicenseServerList()

    You should see the server name in the output.

    Once done this, reboot the system and log in with any user (if using a workgroup, you know your users must be part of the Remote Desktop Users) and the trial period message will dissapear.

    Source of all this mess: http://support.microsoft.com/kb/2833839

    Managing with Powershell

    There are a few things you can manage with Powershell. To see the commands try:

    import-module RemoteDesktop get-command -module RemoteDesktop

    There is a list of commands you can execute via Powershell to manage your box. However, I've tried a few but some of them require you to have some extra features installed, that can't be deployed on the scenario we are talking about.

    The ugly way

    If none of the above works for you, there is a way to reset the grace period to the initial 120 days. Of course, I don't recommend doing this, as the user will keep noticing the message. Of course, you'll need to purchase proper licenses.

    To reset the counter, just delete this registry key:

    HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Grace Period

    Of course, you'll need extra-privileges to do that, executing regedit as administrator will not work. Try this:

    • Get PSEXEC
    • Start a cmd as administrator
    • run psexec -s -i regedit.exe
    • delete the desired key
    • reboot

    Hope some of this works for you. If you do some advances with Powershell and RDS, let us know.

    • 11

  2. As I was setting up an environment in a lab to try this (a simple RDS deployment wihtout a domain), I found the answer to your question, though it's not the one you want to hear.

    RDS in [Server 2012 and 2012 R2] requires all its servers to be added to a domain. That, according to a program manager at Microsoft on the Remote Desktop Virtualization team, who wrote the linked MSDN blog article, Setting up a new Remote Desktop Services deployment using Windows PowerShell.

    So, sorry that it's not the answer you wanted, but it looks to be pretty authoritative to me. You can't do what you want, because Microsoft has decided to make domain membership a technical requirement for RDS servers in Server 2012 and 2012 R2.

    • 7

  3. I did find during testing this it is important to have at least 1 NIC configured with IPv6 enabled. This was required as the loopback to have the RDS License server talk to itself it attempted to resolve via IPv6 to do this (As seen in Pings). I had IPv6 Disabled on both NICs and this caused the server to not loop back properly.

    • 1