2 Methods to Fix “The Group Policy Client service failed the logon. Access denied.”
WSUS Synchronization failed.
Message: Failed to sync some of the updates.
You may experience this problem if a computer is behind a firewall or behind a proxy server.
If you are using WSUS 3.0 with a Windows Internal Database that was created by a default WSUS installation, type the following command:
If you configured WSUS 3.0 to use an existing installation of SQL Server, type the following command:
I was asked to report on how many people were still accessing a legacy Exchange server via Outlook Web Access for the purposes of retiring it permanently. Here is a step by step walk through. Pasted commands may not work. Please type directly into the cmd window!
The first command looks for OWA access
LogParser -i:csv “SELECT cs-username, date, time, c-ip, cs-uri-stem, cs(User-Agent) FROM C:\log\mergedlog\TO C:\log\ WHERE cs-method LIKE ‘%get%’ and cs-uri-stem LIKE ‘%owa%’
This next command lists ActiveSync users
LogParser -i:csv “SELECT cs-username, date, time, c-ip, cs-uri-stem, cs(User-Agent) FROM C:\log\mergedlog\TO C:\log\ WHERE cs-method LIKE ‘%post%’ and cs-uri-stem LIKE ‘%Microsoft-Server-ActiveSync%’
Finally as a Bonus This one looks for Mac Office Users
LogParser -i:csv “SELECT cs-username, date, time, c-ip, cs-uri-stem, cs(User-Agent) FROM C:\log\mergedlog\TO C:\log\ WHERE cs-method LIKE ‘%post%’ and cs(user-agent) LIKE ’%Macoutlook%’
On a Server 2012 RDS farm that has been deployed and working for some time you begin to receive errors stating ‘The remote session was disconnected because there are no Remote Desktop License Servers available to provide a license. Please contact the server administrator.”
You verify your configuration is as expected, that you have valid CALs installed on a Server 2012 terminal server licensing server and that the RD Licensing Diagnoser doesn’t report any errors.
The issue may be that there is a bug with Server 2012 RDS session hosts where they will not look to the licensing server for CALs when the grace period ends. Microsoft are reportedly aware of this but as yet there is no KBA or hotfix for it.
The solution is to open the registry editor on the affected session hosts and browse to the following:
If the ‘GracePeriod’ key exists you will need to delete it.
Note: You will need to give administrators read and write access to the key or you won’t be able to delete it. *(Must take ownership before changing permissions)* Also please observe the usual precautions when working with the registry and take a backup first.
Give your session hosts a reboot and all should be well.
I recently encountered the following errors the event logs of our load balanced RD GW farm:
On the client side we saw the following error:
This error occurs when a active and authenticated session on the web portal gets failed over or load balanced to another RD web portal server. IIS uses an encryption key to encrypt the data, and a validation key to check if the encrypted data is valid (session id, etc). Since the standard setting in IIS is to automatically generate these keys at runtime. The keys are different each time and are different on each members server of the farm. Because of this the web server which gets the session is unable to decrypt and validate the session because it has different keys.
To be able to use the authentication across all member computers in a farm, all the member servers must use the same validation and encryption keys. (Don’t change these settings on a live production environment). The first step is to generate the keys. Open IIS manager and navigate to the server or application, double click on machine key.
Clear all the check boxes “Generate a unique key for each application” and “Automatically generate at runtime” for both validation and decryption keys.
And then click Generate Keys in the Actions pane, and apply.
Copy and paste these keys to the other members of the farm. All new sessions should use these new keys enabling load balancing or fail over between the members of the farm.
Funny thing is, that after I changed this on our servers, I encountered an error on the Microsoft forefront mail site https://sts.messaging.microsoft.com. I was logged on and didn’t do anything for a while. After clicking on a link I saw the following:
I spent significant amount of time trying to resolve this and finally succeed.
This is what you gotta do:
Right click/properties/security/advanced/change permissions/add/advanced/find now./
NOW THE MOST IMPORTANT PART:
(I suggest changing the search location to the local server)
Find the line that states ‘Authenticated users’ Click on that ,OK,ALLOW FULL ACCESS.
It might prompt you to confirm or to restart windows or the file.
The trust relationship between this workstation and the primary domain failed