I had a user complaint over not being able to access a terminal server. He would attempt access and receive an error message:
The Group Policy Client service failed the logon. Access denied.
Since it was a terminal server; I renamed his profile and he was able to access it.
Our monitoring systems reported errors with a terminal server. I tried remote desktop and received the following error:
Remote logins are currently disabled.
Someone with administrator access disabled the logins with the change logon command.
The management console for reasons not pertinent to this issue was not usable at this time. In order to enable the logins, I needed to a way to submit the command.
Time for our trusty friend “psexec”
psexec.exe “\\<terminal server>\ change logon /enable”
After that we could access the terminal server.
Company acquisitions bring new challenges to environments. Such was the case with two servers which are used to test McAfee with the companies product. These servers were moved from a public area to a hardened site. They used to walk up and login when needed but now they could only use remote desktop. They reported the servers were down.
The McAfee fire was setup with a basic configuration and blocked ICMP and but did not block remote desktop.
Ping was enabled and on further review port 3389 needed to be enabled for TCP.
I am “crash and burn” testing windows 10. Painful but a good way to get the feel of it. One painful loss was the Active Directory module for Powershell. You have to have Remote Server Administration Tools (RSAT) and they stopped working for Win 10. There was a special release for the January version of Win10 but it died with the May version and Microsoft reported they will fix it with the general release.
What to do?
I thought about using one of my test VMs running Windows 2008. It had RSAT but when I tried to import the Active Directory module into Powershell; I received an error saying it did not exist.
I found there were a extra other steps needed to be done:
1) Import-Module ServerManager
2) Add-WindowsFeature RSAT-AD-Powershell
After that, I was able to import the active directory module.
-edit- 07/23/15
There was a recent update to windows 10 and it nuked RSAT. Microsoft will basically fix it after the OS is released. *sighs*
I had a request for a server running a tool to allow users to access it via Citrix and not have to enter the URL into the trusted sites.
With old versions of IE, you would simply modify the local GPO for Internet Settings. To my surprise, this was gone. It seems Microsoft decided to favor Global Policies starting with version 10 for such issues. It makes sense when it involves many systems; but It seems overkill for one system. I do not have access to the Domain Controllers so my choices were rather limited.
I decided to play around with the registry and found this could be accomplished by creating a couple keys and dwords.
Using regedit, I drilled down to : HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\Internet Settings\ZoneMap
I created a new key called: EscDomains and inside that another key for the ServerName
This is used when enhanced security is enabled for IE.
Inside this key, I created two new DWORDS : http and https and set both to 2 which signifies Trusted Site.
Not knowing why Enhanced Security was in use for this server, I decide to create a couple more entries in case somebody decided to disable it.
The two new keys went in the ZoneMap\Domains: company.com\servername
Obviously you change that to your domain name and the name of the server.
Inside the servername key I created the same two dwords as before.
After that I tested the access and the users could get the login screen without modifying IE.
Granted not the best solution and caution should be used but it solved my issue.
Information used to research this:
One machine decided it didn’t want to work anymore. The event viewer showed a message logged where the winlogon initiated a shutdown with the Reason Code: 0x500ff.
Not a typical error. Power was ok and there wasn’t anything else obvious.
A Technet question found a similar issue happened to someone else.
The power supply was reseated and so far the system remains up.
We are transitioning our console management setup and one of the Windows systems reported an error when trying to access it through the iLO management port.
Secure Connection Failed
An error occurred during a connection to <FQDN>. SSL peer reports incorrect Message Authentication Code. (Error code: ssl_error_bad_mac_alert)
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Please contact the website owners to inform them of this problem.
It’s an odd error as this was the only system reporting it and it happened on different browsers (IE, Firefox, Chrome).
I tried resetting to factory defaults but that didn’t solve it.
Drivers were up to date but the firmware looked old. I pulled down the latest version and installed it.
Problem solved.
One of the most annoying things is a server which is hung up and won’t allow you to access it remotely. Especially, if it requires driving to get to the server.
Such was the case of a trouble call from a user trying to access a server. He would try remote desktop and received the following message:
Please wait for the System Event Notification Service…
The login process would remain at this point.
Remote Reboot failed but the system would ping and I could mount a hidden drive.
I needed remote desktop to work so I could look into this problem.
The System Event Notification Service as described from an article in the Microsoft Developer Network states:
Applications designed for use by mobile users require a unique set of connectivity functions and notifications. In the past these individual applications were required to implement these features internally. The System Event Notification Service (SENS) now provides these capabilities in the operating system, creating a uniform connectivity and notification interface for applications. Using SENS developers can determine connection bandwidth and latency information from within their application and optimize the application’s operation based on those conditions.
It sounds like something that is not needed, but it wasn’t the time to make this call when there was an annoyed user waiting for the server. I suspected we could at least kill the process and see if Remote Desktop would work again. Time to use the useful SC command:
sc \\servername queryex SENS
This returned:
SERVICE_NAME: sens
TYPE : 20 WIN32_SHARE_PROCESS
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
PID : 976
FLAGS :
Using the PID; I could attempt a taskkill of the sens process.
taskkill /S <servername> /PID 976 /F
This made the login session continue and I had access to the server.
Checking the Net; there are a several situations which could cause this condition. It ranged from removing Live Messenger (which was not installed), registry changes (which didn’t work or didn’t apply) to removing an update (which was not installed).
I had to log out and found the error was back. I used the same taskkill steps and was able to access the server again.
Not seeing the obvious; I figured I would try the “fix most things Microsoft” solution and rebooted.
The error went away.
Sometimes a reboot is all that is needed.
This was a strange problem. I have a simple Windows 2008 R2 server with remote desktop services installed. Everything was properly configured. Plenty of licenses and diagnostics reported the license server was available.
The problem? Can’t access the server through remote desktop. No errors in the logs and the only message available to me was the generic:
Did all the noob checks and I even reloaded Remote Desktop Services, removed and re-added the server to AD.
Still no access.
I installed tightvnc as I did not want to live at the machine and found I had remote access.
I checked the registry to see if port 3389 was configured and it was.
I used portqueryui to see if the port was in use and it reported:
TCP port 3389 (ms-wbt-server service): NOT LISTENING!
A quick telnet to port 3389 confirmed this.
The firewall was not running and there wasn’t a web server or any other process trying to use that port and thus block Remote Desktop Services. I was tempted to declare too much time debugging this and reload but I decided to dig around the Net a little more and stumbled on an old discussion on technet.
As mentioned in the post by itdoug; I found the hidden device driver called “remote desktop services security filter driver” disabled (You just bring up the Device Manager, select show hidden devices and look under Non-Plug and Play Drivers).
I tried to enable it and it failed. I then uninstalled it and rebooted.
Remote Desktop worked after that.
I have a couple servers which crash reboot from time to time.
Looking over the event log, the bug check reported:
The computer has rebooted from a bugcheck. The bugcheck was: 0x0000007e (0xffffffffc000001d
Researching the Net, really didn’t point to an obvious reason. Suggestions offered:
Didn’t find any errors.
Didn’t find any errors.
I decided to update the BIOS and the controller firmware.
So far the systems haven’t crashed.
techdork 