RemoteApp Icons missing from RDWeb

I had this issue recently, where the icons were missing from the RDWeb login page.

Amongst other things the main change to the configuration was a re-IP addressing of my network to place it behind a firewall.

Whilst, most things are achieved through name resolution, I was getting an Error logged in the Application Event log pointing to the OLD IP address of 192.168.0.110.

After checking the configuration, removing/adding settings in the Remote Desktop console, I realised this must be a hard-coded value somewhere.

As it turns out I had committed the unforgivable offence of using an IP address in a configuration file (In my defence this was at home during testing!).

Ensure the ServerName tag in the RDWebAccess.config contains a valid server/alias FQDN (if configured).

C:\Windows\Web\RDWeb\App_Data\RDWebAccess.config

OLD Setting

192.168.0.110


Updated Setting

Server.domain.com


Event Viewer message;

Log Name: Application
Source: RADWebAccess
Date: 8/02/2012 7:39:24 PM
Event ID: 5
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: Server.domain.com
Description:
No programs were detected on 192.168.0.110. Ensure that the server is an RD Session Host server and that it is online.

RemoteApps not populated in RD Web Access because of WMI Rights dissapearing
http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/035c10c0-22c3-4b3f-800c-6af1143f39ab

Remote Desktop Cut and Paste does not work

Issue:

When using RDP you may not be able to cut and paste information between your local and remote sessions.

Cause:

The rdpclip.exe processing may not be running on the remote system. Alternatively, the clipboard chain may be incomplete.

Workaround:

Restart the rdpclip.exe process on the remote system.

More Information:
The following article has a good article on Clipboard chaining;

http://blogs.msdn.com/ts/archive/2006/11/16/why-does-my-shared-clipboard-not-work-part-1.aspx

schtasks /v verbose option may not display expected results

Issue:
When you run "schtasks /query /s [SERVER] /v" on a Windows XP machine, the scheduled tasks utility may not list any tasks.

Symptoms:
The Windows XP schtasks.exe utility (5.1.2600.2180) does not return any output. Task execution does not appear to be impacted by this command line limitation.

Cause:
A scheduled task is configured with a command line exceeding 254 characters.

Executing the command "schtasks /query /s [SERVER]" without the verbose option returns the list of scheduled tasks, however, when the /v option is used to display the extended properties of the task no output is returned.

Workaround:
Use the Windows 2003 version of schtasks.exe (5.2.3790.0) returns task information, although tasks with command lines exceed 254 characters are truncated.

Alternatively, use Windows explorer to view the task information.

Preventing items from being added to the MFU list

The old addage of "Prevention is better than cure" I have found to be true with relation to removing items from the Most Frequently Used (MFU) start menu list.

The following powershell script prevents the Windows Tour icon and Migration settings wizard from being added to the MFU list. Of course, this could be used to prevent any other number of items from being added to the MFU list.

<<<>>>

$TaskDesc = "Clear MFU List"
$AddRemoveApps_New = ";TourStart.exe;MigWiz.exe"
$AddRemoveApps = Get-ItemProperty HKLM:\Software\Microsoft\Windows\Currentversion\Explorer\FileAssociation
-name AddRemoveApps
Set-ItemProperty HKLM:\Software\Microsoft\Windows\Currentversion\Explorer\FileAssociation
-name AddRemoveApps -value $AddRemoveApps$AddRemoveApps_New

# Test to see if the Registry action succeeded
If ($?) {
Write-Host "Enabled $($TaskDesc)"
} Else {
Write-Host "Error:$($TaskDesc) $($Error[0])"
}

Frequently used programs not automatically added to the Start menu
http://support.microsoft.com/kb/q282066/

Preventing users from executing files using Software Restriction Policies

Traditionally I have used NTFS permissions to restrict access for standard user accounts to certain executable files.

Most notably is reg.exe, when providing a managed workstation (SOE) to prevent standard users from accessing the registry. When coupled with Group Policy to restrict access to registry editing tools (regedit) it is effective in preventing access.

One alternative I had overlooked until recently was Software Restriction Policies. These can be applied as per most policies at the local or Group Policy level.

Summary:
A user with full permissions to a directory can be blocked from executing files using the Software Restriction Policies.

Using the "Disallowed" Security level, prevents execution regardless of the NTFS permissions the user holds, using Unrestricted honours the user account NTFS permissions.

Example:
User has Full Control of the folder C:\Test

Create a New Path rule by running GPEdit.msc
Local Security Policy / Software Restriction Policies / Additional Rules (Same location for a GPO)
New Path Rule
Path: C:\Test
Security Level: Disallowed

When the user executes a file from the path, the system prevents execution of the file.

C:\test\notepad.exe
The system cannot execute the specified program.

This could be applied to the SOE reg.exe scenario outlined earlier.

Another use I can see for this is to have a "scripts / tools" directory that the system can execute from Using a local System scheduled task, but those pesky users can't.

The following Microsoft articles list there purported uses of the facility, but this is interesting if nothing else and provides another tool for SOE builds that I hadn't considered using before.


Other rules can be specified to identify software including

Hash. A cryptographic fingerprint of the file
Certificate. A software publisher certificate used to digitally sign a file
Path. The local or universal naming convention (UNC) path of where the file is stored
See also "Registry Paths" as outlined in the reference documents.
Zone. Internet Zone

Using Software Restriction Policies to Protect Against Unauthorized Software
http://technet.microsoft.com/en-us/library/bb457006(TechNet.10).aspx

How Software Restriction Policies Work
http://technet2.microsoft.com/windowsserver/en/library/d24bc8c8-27cc-47ba-9b02-78d9d801e9371033.mspx?mfr=true

SysPrep may not perform FullUnattend as expected

Issue:

When you supply a SysPrep answer file, SysPrep may not process the answer file as you expect. The Mini-Setup wizard stops processing and requests user input.

Cause:

One cause of this may be the use of comments within the SysPrep file. Sysprep.inf comments are denoted by the semi-colon (;) character. When a comment character is included on a line in the Sysprep.inf file, the complete line is omitted from processing.

Workaround:

Move the comment to a separate line of its own.

Example:

AutoMode=PerSeat ; Licensing Mode usually perseat

change the line as follows;

; Licensing Mode usually perseat
AutoMode=PerSeat

GPResult.exe may not complete Group policy report

Issue:
When you run "gpresult.exe /z" on a Windows XP machine, the RSOP may not complete processing.

Symptoms:
The GPResult.exe output is incomplete.

Cause:
A GPO contains the percent ("%") sign character. When the GPResult.exe encounters a % sign in the Group Policy Object, processing is terminated. The version of GPResult.exe with this issue is 5.1.2600.2180.

Typically, the % character may have been used in a Group Policy Computer startup/shutdown script or User Logon/Logoff script, to reference a local environment variable such as %SystemDrive%.

Workaround:
Use the Windows 2003 version of GPResult.exe, this tool is able to parse the % character successfully and completes the RSOP report. Version 5.2.3790.1830 or later of the GPResult.exe tool successfully parses the % character.

Alternatively, the GPMC console is able to generate the RSOP report successfully.