ads

Style6

Style3[OneLeft]

Style3[OneRight]

Style4

Style5[ImagesOnly]

Style2

RemoteApp Configuration for Thin PC


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.
That's It!


Check user session status before using RDP

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!

Hide Windows Update Warnings on RDP /RDS Server

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 Profile Issues on 2012 Remote Desktop Server (RDS).

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.

Edit the User Profile Disks Maximum Size Limits

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! 




Slow Authentication With Remote Terminal Services Gateway

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:







Enable Windows Remote Assistance

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




    Multiple Accounts for Network Administration

    A single account with domain admin membership may put their network at risk if their workstation is compromised; instead a domain user account, in addition to a domain admin account (i.e. jordan & adm_jordan), should be used for best practice security.  The domain user account should be used to log onto a workstation to check email, web surf, etc..  The domain admin account should only be used for administration purposes.
    There are tools available to help a network administrator use multiple on a daily basis.  My favorites are:

    1.  Remote Desktop Management tool can be used to organize and store multiple RDP configurations with a centralized location.

    It can be downloaded at:  http://www.microsoft.com/download/en/details.aspx?id=21101.
    The above tool is especially handy for working with multiple accounts.  Remote administration is easy because of the ability to assign and save user accounts for the connections’ properties.

    2.  To further automate the process I recommend downloading and installing the Windows 7 remote management tools at:http://www.microsoft.com/download/en/details.aspx?id=7887.

    The server management tools will allow domain admins to administer any of the servers from a Win 7 workstation. The tools include AD users, Print Management, DNS, etc… 

    The trick for administrative convenience is to use the “run as a different user” when opening the application. The option is hidden by default in Windows 7. In order to use it, hold the shift key, and right mouse click the program icon.I found this to be a relatively pain free way to manage things. It also keeps the network safer and creates a better audit trail.