This article explains how to fix installation errors for Windows Update installations.
Problem: Windows Updates fails to install on Windows 2008 R2 System Center Data Protection Manager (DPM) server.
Errors: Specific errors may include, "Installation Failure: Windows failed to install the following update with error 0x80070643".
Solution: Delete the Windows Update cache and remove all superseded service pack backup components to resolve the issue. N.B., This situation is not specific to DPM; and can help with other Windows environments, including Windows 8.1 & Windows 2012 R2.
- Stop the Windows Automatic Update Service from the command line:
net stop wuauserv
- Go to the Windows directory from the command line:
cd\windows
- Purge the update cache from the command line:
rd /s SoftwareDistribution
- Start the Windows Automitic Update Service from the command line:
net stop wuauserv
- Remove superseded cumulative Service Pack backup components:
Dism.exe /online /Cleanup-Image /SPSuperseded
That's it.
References:
http://technet.microsoft.com/en-us/library/dn251565.aspx
http://support.microsoft.com/Default.aspx?kbid=971058
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:
- Use the same internal Active Directory domain as the public external domain (thus no SSL issues).
- 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.
- 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.
- 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.
- 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:
Problem: Failing node. Failover Cluster Manager gave the following message:
The cluster network name is not online.
There was also the following system log error:
Solution: When attempting to bring nodes online to the failover cluster be sure to check the network cluster client role. The role must be set to "allow clients to connect through this network"
*Note: Please try the Powershell or GUI method before attempting this registry fix.
Registry fix resolved the issue:
Location: HKEY Local Machine\Cluster\Networks\NIC GUID\Role
Roles:
1. Do not allow cluster network communications on this network
2. Allow cluster network communications on this network
3. Allow clients to connect through this network
The role must be set to "3" to allow the node to participate with cluster. Once the role is properly set the node will become online and work with the cluster.
This is widely reported issue with the Microsoft Failover Cluster services and Microsoft Exchange Server 2010 Database Availability Group (DAG) node.
P.S. This post has been surprisingly popular. Please leave comments if this helps. Thanks! -SMJ
Full Technet URL for this issue can be found at: http://blogs.technet.com/b/timmcmic/archive/2010/05/12/cluster-core-resources-fail-to-come-online-on-some-exchange-2010-database-availability-group-dag-nodes.aspx
Last updated August 29th, 2012 by Steven Jordan
