Windows 7 and error "Could not connect to the System Event Notification Service"

At the moment I work at a company with about 8000 to 9000 workstations. A couple of users called in an issue that they had trouble logging in into Windows 7. Once in a while they got the following error message during the logon process.

“Windows could not connect to the Event Notification Service service. Please consult your System Administrator”

 

Only one or more reboot(s) seemed to bypass the error. This was not an acceptable situation and I was asked to look into this problem.

Environment description:

  • Windows 2008 R2
  • Window 7
  • SCCM 2007 R2
  • RES Workspace Manager 2011
  • App-V 4.6 SP1

Underneath a screenshot of the error message:

System-Event-Notification-Service

After checking the event viewer I noticed that not only the “System Event Notification Service” was failing but also several other services failed to start. Underneath a list of services that are involved.

  • Certificate Propagation
  • Extensible Authentication Protocol
  • Group Policy Client
  • IKE and AuthIP IPsec Keying Modules
  • IP Helper
  • Server
  • Multimedia Class Scheduler
  • User Profile Service
  • Task Scheduler
  • System Event Notification Service
  • Shell Hardware Detection
  • Themes
  • Windows Management Instrumentation

With the knowledge that not only the “System Event Notification Service” service was failing to start I searched the web for a solution. I found several articles but they didn’t solve my problem. Than I stumbled onto the following Hotfix:

http://support.microsoft.com/kb/2590550/en-us?fr=1

This hotfix solved my problem. But in the meanwhile several users were still experiencing this problem. Due a backlog on the change management side, it would take a while to get this hotfix in production. I decided to look for a workaround for the customers who were experiencing this problem more frequently.  It seemed, like described in the article, that the “Microsoft Virtualization client” had something to do with it. I quote:

Cause: This issue occurs when a new drive is added to the system while background services are still starting.  The most common example of this is with Microsoft Application Virtualization Client.  When this service starts, it creates a virtual drive.  When this drive is created during system startup, the Server service may crash the shared service host process.  This process contains other services which are important for completing user logins.  When these services fail at startup, a blue or black background image is displayed instead of the user’s desktop.

When trying to find a workaround I found that delaying the startup of the “Microsoft Virtualization Client” service seemed to work. This should give the other services time to start-up. It’s a quick and dirty method but it did solve the problem for the users who were experiencing this problem on a frequent base. We decided to use it as a temporally workaround until the hotfix was applied.

The hotfix is also applicable for Windows Server 2008 R2 in case you are experiencing the same issues on a server.

Greetings,

How to Launch Vapplauncher with Parameters using powershell

Hello everybody,

At the moment I am working in an environment where App-V is integrated in SCCM 2007. To launch an App-V application the “Vapplauncher” is used. This week I have been asked to package an application with the following requirements.

 

 

The application must be able to start from a Scheduled Task and External Application.

  • The application must start with different parameters.
  • The parameters can change every month and this should be done by the “Super user” (Which has no access to App-V / SCCM)

Starting the App-V application from a schedule or external application is just pasting the Vapplauncher command line into it. However, the Vapplauncher doesn’t accept any parameters. This is why you have to create a extra OSD with the parameters in it. This means that the “Super user” has to change this OSD each month and deploy it through SCCM. Of course this was not an option because of the rights.

The challenge:

  • Start the application with the parameters through: C:\WINDOWS\system32\CCM\VAppLauncher.exe /launch “MyApp”
  • The user must be able to change the parameters each month without having to change the OSD or having special rights.

Solution:

  • Create a networkshare where the user has enough rights to change/write files
  • Place a *.txt file in the share containing the parameters
  • Create a PowerShell script (or more if needed) in the share which can do the following:
  1. Get the content of the *.txt file
  2. Start the application with the parameters found in the *.txt file which is edited by the user
  • Create an OSD to start the PowerShell script
  • Give the user the command line to start the OSD so it can be used in a schedule or External application

Components of the solution:

Networkshare: G:\MyApp\Test\
*.txt file for user: G:\MyApp\Test\MyApp_parameters.txt
PowerShell script: G:\Myapp\test\Script\Start_Myapp.ps1
App-V package: With at least one OSD that starts the application with the powershell script

The powershell script:

These are the basics of the script. Of course you should adept it to your needs with logging and checking on existing files etc. But now you will have a start.

This is the starting line you should use in the OSD:

The command line to start the application is:

Thank you for reading. I hope it will be useful for you. If you have any comments or questions you can use the comments underneath or the PM system to ask questions.

Greetings,

Joey Steenstra

SCCM 2007 R2 Error unregistering notification query CcmExec

Not to long ago we had some issues (re)deploying Windows 7 (including the baseline) on our client systems.  One out of three systems failed during (re)deployment.  At first we thought it was because the systems were not removed correctly from SCCM before redeployment. Further investigation told us that the deployment also failed on new systems and systems which were correctly removed from SCCM before redeployment.

Environment description:

  • Windows 2008 R2
  • Window 7
  • SCCM 2007 R2
  • RES Workspace Manager 2011
  • App-V 4.6 SP1

Description:

CcmExec.log logged the following:

“Error unregistering notification query CcmExec“ occurs after a restart initiated by the installation of the App-V client. It seems that CcmExec (SMS Agent Host  service) is having trouble to start. After a while it times out and the (re)deployment fails. The restart which is needed after the installation of the App-V client is the first restart initiated by an application after the windows installation. It could be possible that this error also occurs after other installations where a reboot is needed. Unfortunately we haven’t run tests on this, we only have one installation which needs a reboot during this phase.

Solution:

By delaying the auto startup of the CcmExec service we solved the (re)deployment issues in this case. The CcmExec service will start after all other services who are configured as “Automatic” startup. Normally this is used to shorten the boot time but in this case it also helps us preventing (re)deployment failures. Right before the installation of the App-V client we added a “Run command line” to the task sequence as follows.

Type: Run Command Line
Name:  Delay startup CCMexec service
Description: Delay CCMexec (SMS Host Agent) service
Command line:

Before the last action of our task sequence will take place, in our case a last reboot to complete the deployment, we added the following “Run Command Line”.

Type: Run Command Line
Name:  Automatic startup CCMexec service
Description: Sets CCMexec (SMS Host Agent) service on automatic start without delay
Command line:

This was our solution for the (re)deployment problem we encountered and hopefully it will help some of you who experience the same problems. If you have any comment or questions you can post them down below in the comment section.

Greetings,

Marco Nuijens