Archive for the ‘2008’ Category

Please wait for the System Event Notfication Service…

Thursday, August 7th, 2014

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.

 

Can’t remote desktop to a windows 2008 R2 server

Tuesday, June 17th, 2014

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.

 

c:\hpssbem.exe is not a valid win32 application

Sunday, October 20th, 2013

Today was a new message.  I was supposed to convert two Linux servers to Windows 2008 Server.  The two servers are HP DL360 G5s.  Old but still usable as they were going to be workgroup servers.

The install procedure was to use the HP Smartstart CD.

One server converted without issue but the other after going through these two steps:

X:\windows\system32 > wpeinit
X:\windows\system32\ C:\hpssbem.exe

Gave the interesting error message of:

C:\hpssbem.exe
C:\hpssbem.exe is not a valid Win32 Application

Wait?……..This is a 64bit install?…….Why would it want a Win32 application?……..

I tried a restart.  I tried to rerun the install and even formatted the disks but the same error occurred.

Finally, after clicking OK and using the console window; I had a look at the hpssbem.exe and found it’s size was “0.”   Rather odd as why would there be a copy problem if it worked on the previous server?

I inserted the Smartstart CD again an located the application at:

<cdrom>:\compaq\install\w2k8x64

I copied hpssbem.exe to C:\ and re-ran wpeinit which started the installation of the OS.

Powershell: Direct output to a variable.

Thursday, July 25th, 2013

I was asked if there was a way to capture output of a specific program to a variable.

Basically, the person wanted to get a version number from the program.

Played around and had a way to accomplish this  but I found a simpler approach.

$scriptOutput = & "c:\path\program.exe" -V 2&1

Obviously, the -V works with the program in question.

I am liking powershell

The account used is a computer account. Use your global….

Thursday, July 25th, 2013

While scripting a report; I noticed a bogus error about a file version being wrong.

I examined the server in question and found the server service was not running.

I tried to start it but it stopped right away with the following message in the system event log.

The Server service terminated with the following error:
The account used is a computer account. Use your global user account or local user account to access this server.

Another server with the same problem would give this message:

Windows could not start the Server service on Local Computer Error: 1808: The account used is a computer account. Use your Global user account or local user account to access this server.

The service was configured correctly.

An odd problem and it’s cause was the fact a couple users placed URLs in the system Path variable (ie \\server\mount\dir).

Removing the entries and a reboot of the server corrected the issue.

You must be an administrator running a console session…..

Tuesday, July 9th, 2013

I was trying to debug a problem on a remote server through remote desktop.

I wanted to run a Windows File Protection scan (sfc) but was rewarded with:

You must be an administrator running a console session in order to use the sfc utility.

I looked at Microsoft and found this technote.

The resolution was was to run it locally as this was by design!!!!

I thought “Come on! I have to drive over to the machine!”

Then, I noticed “Applied To” and saw only Server 2000 listed.

Hmmm?  Administrator?…..

What would happen if I started a command window as a local administrator (right click the menu option and select run as administrator)?

Success!

Lesson of the Day:  Read the whole technote!

Event filter with query “SELECT * FROM __InstanceModificationEvent WITHIN 60

Monday, February 11th, 2013

I happen to notice this error would pop up on the application log every time a windows 2008 R2 server was booted:

Event filter with query “SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA “Win32_Processor” AND TargetInstance.LoadPercentage > 99″ could not be reactivated in namespace “//./root/CIMV2” because of error 0x80041003. Events cannot be delivered through this filter until the problem is corrected.

It didn’t seem to be bothering anything but why have an error if you can eliminate it. I did some checking around Microsoft and found this.

Normally, I like to review and run the script.  I had other things to handle so I let the fix-it routine handle it.  A quick reboot and there was no message logged.

 

Could not start PsExec service on host

Saturday, February 2nd, 2013

I have a script which uses psexec to check a few things on new servers. I ran the script and received the following message.

Couldn’t access *hosta*:
The handle is invalid.
Could not start PsExec service on *hosta*:
Access is denied.
Starting PsExec service on *hosta*…

Rather an odd message because another server with the same configuration didn’t have a problem. I checked a few things but did not find anything obvious. Server pings, remote desktop works, etc., etc…..

From the other box I tried to see if I could remote access the C drive via \\hosta\C$ and received this error:

\\hosta\C$

Logon Failure: The target account name is incorrect

The AD account looked ok but when I checked the host; I found a typo.  Instead of *hosta* there was *hosa* (obviously not the real name but you get the idea).

I deleted the domain account and simply renamed the server.  The domain prompted for an admin level account to do this and rebooted.

Don’t forget to move the host to the proper AD group if you use them.

Moral of the story: DNS/AD is both a friend and enemy. DNS pointed to the correct server but simple things would not work while other things like remote desktop did.  Well? Only because a previous problem prompted for a change in the negotiation level of RD.

It’s funny but I look back to my first AD design course and I remember the teacher repeating most AD problems are DNS related.

This could be caused by an outdated entry in the DNS cache.

Saturday, February 2nd, 2013

I was setting up a new server and when it came time to test a few things; I received this nice message when I tried Remote Desktop:

The connection cannot be completed because the remote computer 
that was reached is not the one you specified. This could be caused
by an outdated entry in the DNS cache. Try using the IP address of 
the computer instead of the name.

I checked the cache and DNS and found it was in order. Remote desktop would work with the IP address.

This was one of two machines with the same setup and the configuration matched the other machine. I checked the Microsoft site and found this.

All you need to do is:

  1. Start > Administrative Tools > Remote Desktop Services > Remote Desktop Session Host Configuration.
  2. Look under Connections and Right-click the RDP listener (Connection name is RDP-Tcp) and select properties.
  3. Look in the security box where you should see the security layer is set to negotiate.
  4. Change it to RDP Security Layer via the drop down button.
  5. Click OK and close the Remote Desktop Session Host Configuration.

After that; Remote Desktop by hostname works.

I can’t explain why this happened on one of two identically configured systems. I could go back and hunt for a reason if I had time which I never do of course….

*update*

Well now. While working on another issue; I found the problem. The hostname was misspelled on the host. DNS and AD managed to give functionality but other things like simply mounting the C drive \\host\C$ failed giving the error “The target account name is incorrect” A quick delete of the domain record, a reboot and the problem is solved.

How to show hidden files in Windows 2008

Friday, January 11th, 2013

Every major release of an OS brings changes to the layout. Such is the case of showing hidden folders on server 2008.

To enable hidden folder:

  • Open the C drive and look to the left for the organize menu.
  • Click it and select Folder and search options
  • Click the View tab.
  • Click the circle for Show hidden files, folders, and drives.
  • Click OK

The hidden folders and files will now appear.