Problem:

How to disable the unexpected shutdown prompt for remote desktop users.  The remote desktop server (RDS) displays the shutdown tracker warning after patching updates.  This shutdown error causes confusion and unnecessary help desk calls.

Solution:

Remove local\Users group permissions from shutdown.exe:  c:\windows\system32\shutdown.exe

 

Both local administrators and local users, have read and execute permissions, on this system file.  Remove the local user group in order to hide unwanted shutdown messages.  Also note, this change may require ownership changes from the Trusted Installer to the local administrator group.


That's It!

Problem:  

RDP users cannot install Chrome extensions from the Chrome Web Store.

Errors:

• Could not install package
• COULD_NOT_GET_TEMP_DIRECTORY

Figure 1:  Chrome Temp Directory Error

Solution:

1. User logs onto RDP.  User does not open Chrome.
2. Admin creates a new directory on the system drive.  This new directory holds user Chrome AppData.  For example:  c:\\mkdir c:\Temp\RDP\
3. Move user’s Chrome AppData to the new directory.  For example:
   c:\move "c:\users\stevenjordan\AppData\Local\Google\Chrome" "c:\temp\RDP\stevenjordan\"
4. Delete original folder if necessary. 
5. Create new symbolic junction where the old data was located.  This junction links to the new location:

c:\mklink /j c:\users\stevenjordan\AppData\Local\Google\Chrome\
"c:\temp\RDP\stevenjordan\Chrome\"

Junction created for c:\users\smjordan\AppData\Local\Google\Chrome\
=== c:\temp\RDP\stevenjordan\Chrome\

Figure 2:  New Symbolic Junction for Chrome extension.

Analysis:

Chrome extensions reference DOS device paths.  Let's consider how dynamic profile disks use symbolic junctions that point to different disks:

c:\Users  dir 
02/23/2018  11:29 AM  bgates {\??\Volume{a5ae22c7-18b8-11e8-968e-00145de79140}

The junction link causes the problem.  Ironically, a second junction link fixes this issue:

c:\Users\bgates\AppData\Local\Google dir
 
 Directory of c:\Users\bgates\AppData\Local\Google

02/20/2018  10:58 AM   DIR
02/20/2018  10:58 AM   DIR
02/20/2018  10:58 AM   JUNCTION  Chrome c:\temp\RDP\bgates\Chrome
09/16/2015  07:46 AM   DIR       Chrome Cleanup Tool
05/14/2014  06:09 AM   DIR       CrashReports
03/11/2014  04:26 PM   DIR       Google Talk
12/04/2017  02:27 AM   DIR       Software Reporter Tool

0 File(s)              0 bytes
7 Dir(s)  36,942,458,880 bytes free

Note how the new junction link points to the system drive.

Additional Thoughts:

This solution is implemented on a per-user basis.  It does not universally "fix" Chrome extensions for all RDP users.  Nonetheless, it may be a good fit because it narrows the scope of untrusted applications.

Alternatively, use Group Policy to change user environmental variables:

Group Policy
→ Computer Configuration
      → Administrative Templates
         → System
            → Group Policy
               → Configure user Group Policy loopback processing mode:
                       Enabled:  On
                       Mode:  Merge

   → User Configuration
      → Windows Settings
         → Preferences
            → Environment (right-click) → New
               → New Environment Properties:
                      Action:  Update
                      User Variable=Check
                      Name=Temp
                      Value=c:\Temp\RDP\%USERNAME%
              → Environment (right-click) → New
                      Action:  Update
                      User Variable=Check
                      Name=TMP
                      Value=c:\Temp\RDP\%USERNAME%

This change has a wider-scoping impact.  It affects all related AppData programs -not just Chrome.  It impacts all RDP users (without GP filtering).  Avoid the system drive if possible -use a secondary disk instead.  In addition, loopback processing applies user configurations to computer objects (i.e., RDP servers).

That's It!

References:
https://blogs.technet.microsoft.com/grouppolicy/2009/05/13/environment-variables-in-gp-preferences/
https://devtidbits.com/2009/09/07/windows-file-junctions-symbolic-links-and-hard-links/
https://blogs.msdn.microsoft.com/jeremykuhne/2016/04/21/path-format-overview/
https://blog.brankovucinec.com/2017/01/09/users-cant-install-google-chrome-extensions-on-rds-farm/

Problem:  How to auto-config RemoteApp webfeed on Thin PC.

Solution:  Push the RemoteApp webfeed URL via GPO registry

1. Launch Registry Editor with regedit.
2. Locate the following hive:  HKEY_LOCAL_MACHINE -> SOFTWARE -> Microsoft
3. Create a new key in the above hive:  Name the key:  Workspaces.
4. Create a new key in the newly created Workspaces hive.  Name the key:  ResourceType.
5. Restart.

Problem:

How to determine whether a user is logged onto a workstation remotely.  For example, the help desk wants to remote desktop to workstation for maintenance purposes.  This task requires that no other user is logged onto the workstation.  Help desk does not want to disrupt any staff that may be working on the computer.

Solution:

Use Query Windows Station (qwinsta) to list active sessions:

qwinsta /server:hostname_or_IP

Hint:

Combine this with the reset session command as needed:

reset session {SessionName | SessionID} [/server:] [/v] That's It!

Problem: 

   Staff receive Windows Update message when logging onto the RDP server.  This problem confuses end users and causes unnecessary calls to help desk. 

Background: 

   Remote desktop servers receive regular updates on Patch Tuesday. However, this problem was accentuated after Microsoft changed their patching policy to expedite out-of-band patches. 

Solution: 

Create new GPO policy to hide Windows Update messages on the RDP server.

    GPO Setting Path:  

      User Configuration\Policies\Administrative Templates\Windows Components\Windows Update

    GPO Policy:   

      Remove access to use all Windows Update features 

    GPO Attribute:  

     Enabled: 0. Do not show notifications. 

Note:  

   This is a User Configuration setting -not a Computer Configuration.  Enable Loopback processing to ensure changes apply to all users that logon.  

    GPO Loopback Path:

      Computer Configuration\Policies\Administrative Templates\System/Group Policy\

    GPO Loopback Policy: 

     Configure user Group Policy loopback processing mode

    GPOLoopback Attribute:

     Enabled

   

Fix Temporary Profiles on RDS Server.

Problem:  Users receive temporary profiles each time they log onto the Remote Desktop Server.  The problem is not uniform and may only occur for individual users.

Possible errors may read, "Windows cannot find the local profile and is logging you on with a temporary profile.  Changes you make to this profile will be lost when you log off."

Background:  RDS server is configured with User Profile Disks (UPD).  The problem usually occurs when the user session state is disconnected.  Although the user is not connected their sessions continue to run in the server background -therefore their UPD remains attached to the RDS server.  Users will receive temporary profiles if their UPD was attached to the RDS server when it was restarted.

How to fix temporary profile issues:

1. Have user log off the server.  Do not allow users to log on while troubleshooting.
2. Attempt to delete the temporary profile from Advanced System Properties:
   
   Go to Control Panel → System → Advanced System Properties → Advanced → User Profiles → Settings.
   
   Delete any profiles with Type set as TEMP.
3. Delete any temporary use profiles from the ProfileList in Regedit.
   
   Open Regedit:
   HKLM\SOFTWARE\Microsoft\Windows NT\Current Version\ProfileList
   
   Profiles are listed using objectSIDs, for example:
   S-1-5-82-3848493281-17249319953-1783664087-774473773-2625933694
   
   Identify and delete any objectSIDs that have a .bak suffix, for example:
   S-1-5-82-3848493281-17249319953-1783664087-774473773-2625933694.bak
   
   N.B., each objectSID profile has an expandable string value called ProfileImagePath.  Use this string value to easily identify individual users, for example:
   
   Value Name:  ProfileImagePath
   Value Data:  C:\Users\BGates


4. Finally, manually delete any temporary profiles located in c:\users\, for example:
   
   TEMP.Domain.000
   TEMP.Backup-0

How to prevent temporary profiles issues (i.e., mitigation):

Set GPO policy to log off disconnected sessions after X minutes.   This will reduce the likelihood that UPDs will remain connected if the server is restarted or loses power.

Additionally, ensure all user sessions are logged off and do not allow new connections to hosts before performing maintenance and/or restarts.

Changing the Default UDP Maximum Size.

Last updated  March 1st, 2014 by Steven Jordan.

Takeaway:  This article explains how to change the default maximum size limit for User Profile Disks (UPD) in the Remote Desktop Services (RDS) Session Collection.

Windows 2012 R2 provides User Profile Disks (UPD) to store user profiles on individually assigned VHDX drives.  The RDS Session Collection wizard enables UPD and configures the collection's attributes (e.g., network share).  Initial configuration for the default UPD maximum size is simple; changing the default maximum size requires some extra work.

Background:  Exercise caution when configuring the RDS Session Collection UPD maximum size.  The UPD maximum size sets the default size for each users' VHDX.  I thought 1GB per UPD would be sufficient; if not excessive.  After all, most 2008 roaming profiles are around 50MB.  I found I misjudged the 1GB maximum after an employee complained of an "out of space" errors.

Problem:   The 1GB UPD maximum size limit caused two problems:

1. The user's VHDX size limit is insufficient.  The individual's VHDX disk requires re-sizing.
2. The default UPD size is insufficient.  New profiles (i.e., VHDX) are based on the UPD Maximum Size, located in the RDS Session Collection properties.  The Properties GUI allows changes to all UPD attributes; except the maximum size field!
   
   Once the default UPD size is set, the Maximum size (in GB) is grayed out and cannot be edited:

Solution:  

  The best solution is to plan ahead.  Each UPD (i.e.,VHDX) is thin provisioned so it's OK to over-provision.  The size of a dynamic VHDX disk equals the size of its encapsulated contents.  UPDs provisioned for 100GB will (most likely) use less than 1GB of physical drive space.

In addition, Windows 2012 R2 includes improved SMB3 protocols.  SMB3 breaks the conventional wisdom regarding user profiles.  File transfers using Windows 2008 technology (i.e., SMB2) are lucky to achieve transfer rates of 100Mbps across a 1Gbps switch.  In contrast, the same file transfers via SMB3 nearly saturate the 1Gbps ports.  SMB3 leaves SMB2 in the dust!

Better yet, disks (at least my disks) cannot keep up the data transfers using 10Gbps Infiniband ports.  The physical hard drive, not the network, becomes the bottle-neck.  The crazy-fast transfers makes it is perfectly OK to to host a large UPD (e.g., 50GB) on a 2012 R2 network share.  User profiles are officially antiquated because of SMB3.

For those that cannot predict the future, these are my resolutions to the two stated problems:

1.   2012R2 includes tools to expand or shrink individual VHDX disks.  There are two necessary steps to expand the UPD:
   
   A) Expand the VHDX from any 2012 R2 Hyper-V server.   The Hyper-V Manger simplifies the VHDX expansion with a wizard based Edit Disk tool, located in the Actions menu.
   
   B) Extend the NTFS volume on the VHDX.  Mount the VHDX to any 2012 R2 server and use the the disk manager to extend the disk.
   
   Additional example:  http://adfordummiez.com/?p=460
   
2. The RDS Session Collection's default maximum size setting cannot change from the GUI.  The work around is to simply re-size the default UPD.  That's it!
   
   The Collection Session properties will not update to reflect the new UPD maximum size. The grayed out size limit will remain inaccurate, however all new UPDs will match the newly expanded VHDX.  Does anyone out there know where to change this setting in the registry?  If so please post! 

By Steven Jordan on 10/13/2013.

Problem: 

     Users experienced slow authentication with Terminal Services Web Access applications or remote desktop. Authentication to the RDWeb Work Resources RemoteAPP and Desktops functioned properly. Slow authentication occurred after an application launched.  Authentication time was between 30 seconds to 120 seconds (or longer).

     Warning message, "The identity of the remote computer cannot be verified.  Do you want to connect anyway?"  Problem occurred under similar circumstances for both Windows 2008R2 Remote Desktop Server and Windows 2012 Remote Desktop Services server. 

 Issue:

     The problem for the 2008R2 server resulted from a hostname and SSL certificate name mismatch.  Terminal server settings matched the hostname.  Terminal gateway settings matched the name on the SSL certificate (though different from computer's host name).

     The problem for the 2012 server resulted from a disjoint domain suffix.  The company used a legacy domain suffix of "example.local".  The Active Directory domain suffix was different from the public domain name of "example.com".  In this situation the hostname was correct but the suffix mismatch caused longer than expected authentication.

     Resolution:

     Identifying the problem was the difficult part.  There are a number of strategies to work around this requirement:

1. Use the same internal Active Directory domain as the public external domain (thus no SSL issues).
    
2. Windows PKI Certificate Server can be used but it is not necessary.  Use a self generated SSL certificate to match the domain joined hostname and suffix.   This may not be the best fit for all organizations because it results with a warning to end users that indicates the certificate is from an untrusted source.
   
   If the RDP service is intended for managed resources (domain laptops) the self-generated certificate can be distributed to domain computers' trusted root through group policy.
   
   Staff that connect with personal computers they may choose to discard the warning and import the certificate to prevent further warnings.  This may be a headache for anyone that has to support more than a few end-users.
    
3.  Change the RDP server's domain suffix.  Make the change under Control Panel > System > Computer Name > Advanced > domain suffix.  I should disclose I have not attempted this option so I cannot confirm it will work.  I have read (see references) instances where it has worked for others.
4. Choose not to use the Remote Terminal Gateway and stick with with a natted VIP on port 3389.  This is not recommended best practice but at least the connection is encrypted.  If this method is used do not choose "low security" because in certain circumstances the data may not be encrypted both directions.  Always choose the "medium" or "high" security levels. 
   
   This solution only allows a Windows RPD client to connect.  Advanced features like Web Applications and load balanced terminal server farms will not be available.
5. The best option is to install Terminal Gateway server on a stand-alone (non-domain) server.  The stand-alone server should sit in the DMZ and only connects to domain resources individually exposed to the perimeter.
   
   This solution maintains best security practices.  The solution also allows for a naming convention that is independent of the Terminal Server's host name and domain suffix!
    

* My personal experience with slow RDP authentications was always related to discrepancies between server names and SSL certificates.  Good luck!  

References:

•  http://technet.microsoft.com/en-us/library/aa998420(v=exchg.80).aspx
•  http://blogs.uw.edu/uwwi-blog/2012/12/14/computer-primary-dns-suffix/
•  http://blogs.msdn.com/b/rds/archive/2009/07/31/rd-gateway-deployment-in-a-perimeter-network-firewall-rules.aspx

Problem:   

 IT support staff require an easy method to support remote staff.  Microsoft Lync provides remote desktop viewing but it does not provide Administrative assistance.  Third-party solutions exist but require subscriptions, etc. 

Solution:

 Enable Windows Remote Assistance (RA).  Windows Remote Assistance has improved from the Vista days when it was first released.  When properly enabled, IT staff can initiate an unsolicited RA session to any workstation on the domain; the entire process is simple and intuitive.

Enable RA:

   First, create a "Remote Assistance" GPO within Group Policy Management. Within the GPO there should be 2 policies enabled:

    First GPO:

Computer Configuration\Administrative Templates\Network\Network Connections\Windows Firewall\Domain Profile\Windows Firewall\Define inbound program exceptions:  enabled.

    Add Exceptions to GPO Attribute:

%WINDIR%\SYSTEM32\Sessmgr.exe:*:Enabled:Remote Assistance
%WINDIR%\PCHealth\HelpCtr\Binaries\Helpsvc.exe:*:Enabled:Offer Remote Assistance
%WINDIR%\PCHealth\HelpCtr\Binaries\Helpctr.exe:*:Enabled:Remote Assistance – Windows Messenger and Voice

   Second GPO:

Computer Configuration\Administrative Templates\System\Remote Assistance\Configure Offer Remote Assistance:  enabled.

    Create RA Security Group:

Specify AD security group or users to permit remote control of domain workstations.

Assign the RA GPO to workstations OU.

Once the RA policy has propagated the workstations are ready for administrative remote assistance.

Managing RA: 

   Providing remote desktop support is a simple process.  IT staff can run the following command to start the remote session:
Msra.exe /offerRA computer-name
   The Msra command works with both hostname (i.e. computer name) or IP address.  Msra starts the remote session with an end-user request.  The end-user receives a pop-up window that requests permission to start the RA session.

That's It!

References:

http://technet.microsoft.com/en-us/magazine/ff356868.aspx

Remote Desktop Management Tool: