Since when did Windows update become such a pain to update?

Just for a little background I’ve had this error on a number of occasions. WSUS is installed and configured within the environment, Windows updates are filtered and applied from WSUS (v3.2) running on Server 2003. The clients are configured using an update GPO. Windows firewall on the domain is turned off.

Servers are allowed outbound with no Firewall restrictions on the Cisco ASA

Clients aren’t allowed outbound with Firewall restrictions on the Cisco ASA. (They have internet access via a Proxy Server and I.E. settings are configured via GPO and a PAC file)

Error: 80072F78

After installing a new Windows Server 2008 R2 server I was greeted with this error after adding the server to the domain and performing manual windows updates. The error was displayed after clicking the “Check online for updates from Windows Update” – Although I want to apply the updates from WSUS I wanted to ensure that it was obtaining the latest updates as some may not have been approved.

I checked out some forums and found that this is a known issue with the “authroot.stl” cert installed. I downloaded a newer version and installed:

1. Download: http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab
2. Extract
3. Install (using the default settings, next, next, finish)

This didn’t work straight away until I reset all settings in I.E. 9.0 | after which the error disappeared and I could view the update options (or in my case no updates)

Although this resolved my issue it may not for all! I did find a number of different error codes and suggested fixes on my internet travels, most of these relating to proxy or connection restrictions. Microsoft have documented some debugging steps here: http://support.microsoft.com/kb/836941

Download the “Client Diagnostics Tool”

http://technet.microsoft.com/en-us/windowsserver/bb466192.aspx

netsh winhttp reset proxy

1. wuauclt.exe /detectnow

Update: OK I thought the above would work… apparently not!

OK the secret is in this file:

C:\windows\windowsupdate.log

Delete the entire registry key HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate

Which will revert the WUAgent to the original installed behavior of Automatic Updates and then set the desired behavior usign the Control Panel | Windows Update dialog.

Reference: 

https://www.trustwave.com/support/kb/KnowledgebaseArticle10726.aspx

I recently setup a new server on a 192.168.x.x LAN IP range. The server was prepped ready to be taken to another site on the 10.0.x.x range. By pre-creating the DHCP component in the 192. zone it caused the DCHP IP to be listed incorrectly when running the netsh command below. This IP was listed even through all other aspects of DHCP and DNS were configured correctly.

Netsh dhcp show server >> c:\info_dhcp.txt

In order to correct this I used the NETSH tool.

Net stop dhcpserver
Netsh DHCP delete server DHCPserver.local 192.168.x.x
Net start dhcpserver
Netsh DHCP add server DHCPserver.local 10.0.x.x

Reference:

• http://support.microsoft.com/kb/303351
• http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/aeff964c-7040-42dc-92a6-6de5732598d4
• http://msmvps.com/blogs/ad/archive/2008/06/03/active-directory-health-checks-for-domain-controllers.aspx

I see this error quite a few times when users logon to the Windows Server 2008 R2 RDS/TS server. The fix is pretty simple.

Use “regedit” and navigate to this entry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Find the entry with .bak listed and delete it. When the user logs back in the profile will be recreated.

Source: KB947242

In order to rename a Windows system remotely you need to use the NETDOM command:

The command has been knocking about for a while now and is standard in Windows 2008. In Windows 2003 you can find it in the Windows Resource Tool Kit

Example:

netdom renamecomputer old_name /newname:new_name /userd:domain_admin_login /passwordd:domain_admin_pwd

netdom renamecompuer domold-W7 /newname:domnew-W7 /userd:administrator /passwordd:Passw0rd

In order to carryout an offline domain join you can use the following steps using an admin account or permissions to perform domain joins etc:

Logon to Domain Controller or Server (2008 / 2008R2)

djoin /provision /domain mydomain.com /Machine WorkstationName /SaveFile C:\Off-CLI.DJoin

/domain – Specifies the name of the domain to join.
/Machine – Specifies the name of the computer that you want to join to the domain.
/SaveFile – Saves provisioning data to a file.

Logon to the client PC/Workstation/Laptop (Windows 7)

djoin /RequestODJ /Loadfile C:\OFF-CLI.Djoin /LOCALOS /WINDOWSPATH %systemroot%

/Loadfile – Specifies the output from a previous provisioning command. (Where the offline file is)
/LOCALOS – Specifies the path to the Windows directory of the offline image.
/WINDOWSPATH – Specifies the path to the Windows directory of the offline image. (who doesn’t put this on c:\??

Don’t try and run this same piece of import code for other machines. The djoin import is unique to the PC name, therefore you will create a conflict. I found this out the hard way by getting “The trust relationship between this workstation and primary domain failed.” Error. If you do get this error message simply run through “My Computer -> Properties -> “Network ID” Wizard” or remove it from the domain and rejoin.

This is a nice little method for easy domain join, although have found that even with the system added to the domain you still can’t login as a user in order to create/setup their profile, so without a fully automated install / setup process it doesn’t save much time.

Microsoft DJoin Syntax: http://goo.gl/J7vsV

Setup of “Remote Desktop Services Profile” Paths.

This allows the direction/location of user profiles when using “RDS” although this process may seem straight forward, I forgot the config for this (must have been one of those days)

You can also configure this using GPO which will overide this setting. The GPO is located under: “Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Profiles”
If you get the “Your interactive logon privilege has been disabled” in the RDP connection you need to untick the “Deny this user permission to log on to any Terminal Server” Again this can be set using GPO.

Remember the “Local Path” is purely for a local drive i.e. C:\ D:\ and the Profile path can be mapped to a hidden share, this will prevent users getting confused where their files are if they also operate from a home folder which is visible on the network.
Excellent Best Practice on folder redirection in RDS here: http://goo.gl/aF5kB (Probably best just to follow this guide for it all)
Sources: http://technet.microsoft.com/en-us/library/cc742820.aspx

Updating “Remote Desktop Services Default Connection” text

Server 2008 R2
Edit the entry in the RDWebAccess.Config file.
C:\Windows\Web\RDWeb\App_Data\RDWebAccess.Config (Default location)

Server 2012 (Powershell):

set-RDWorkspace SYNTAX Set-RDWorkspace [-Name] [-ConnectionBroker] [-Name]

Example:

set-RDWorkspace -Name "My Remote Desktop Name here BLAH BLAH"

Adding “Remote Desktop” icon to the Remote Apps list: 

Click on Parameters and select the Always use the following command-line parameters. Type the following in the text box: /v: <FQDN of the RDSH server>.

References:

• Publishing RemoteApps and Remote Session in Remote Desktop Services 2012

Just a quick not to clarify what each option actually does…

Disconnect: Disconnects a user from a session. The session remains attached to the terminal server in the disconnected state and currently running applications continue to run. When you attempt to reconnect to the server, you are reconnected to the same session from which you disconnected, even if you are reconnecting from a different computer. Applications that were left open when you disconnected remain running when you reconnect to the session, with no loss of data.

Reset: Enables you to delete a session instantly. Be aware that resetting a user’s session without warning can result in loss of data at that session. Reset a session only when it malfunctions or appears to have stopped responding.

Loggoff: Enables you to log off a user from a session on the server. Be aware that logging off a user without warning can result in loss of data at the user’s session. When you log off a user, all processes end and the session is deleted from the server.

Source: technet.microsoft.com