New vCenter 4.1 server has "check new notifications" task queued a lot

[PaulITGuy]

Any ideas why I would see like 30 tasks in my vCenter console showing "check new notifications" with a status of Queued? See screenshot.

[Troy_Clavell]

Probably VUM?

[PaulITGuy]

What does VUM stand for?

[Troy_Clavell]

VMware Update Manager. You have it installed in your environment, and if so, did you update it when you updated vCenter?

[PaulITGuy]

This is a new vCenter server. We decided not to upgrade, we created a new one.

[PaulITGuy]

I restarted the service and so far the message hasn't showed up again.

On an unrelated note, does running the "services.sh restart" from the cli console on a ESXi 4.1 host affect the virtual machines running on that host?

[Troy_Clavell]

I restarted the service and so far the message hasn't showed up again.

Glad to see you got it resolved!

On an unrelated note, does running the "services.sh restart" from the cli console on a ESXi 4.1 host affect the virtual machines running on that host?

no, this will have no impact on any running guests.

[PaulITGuy]

services.sh restart does appear to restart the HA service, which means that host may not send an HA heart beat for a few seconds or minutes (depending on service restart time). So this is probably a bad idea for a ESX host in an HA environment running guests, correct?

[Troy_Clavell]

no, this will not cause an HA event. As long as the other ESX Hosts in the environment have heartbeat to each other, you will be fine. It will not affect any networking components.

[PaulITGuy]

This is good to hear, but I will have to test. I am skeptical. Given the amount of experience you appear to have I should just take your word for it, but I like to see things my self.

[PaulITGuy]

I got an email from vCenter saying my host was down when I restarted the services (services.sh restart) earlier. This was when my host had no VM's running and while it was in maintenance mode, and it still triggered some alerts. This is why I think restarting the services while in production will trigger some events and alerts.

[Troy_Clavell]

the host going into a not responding state is normal, as you are restarting a few things, including hostd.

Test as you may, I promise you though, restarting the management agents will not trigger an HA event.

[Troy_Clavell]

I'm pretty sure it has something to do with VMware Update Manager. As you can see in your screen shot it shows a queued item for "download patch definitions" I would try and restart your VUM service and see what happens.

[mrkelder]

Had the same problem and found this post, but still no solution to the issue.

What did work is:

Be sure all you clients are updated to the latest build of vSphere Client.

The Client download link on thevSphere webpage can point to an older build of the Client.

So download the latest build from VMware.com and replace this "VMware-viclient.exe" with the one you downloaded. (rename needed)

Located @ C:\ProgramData\VMware\VMware VirtualCenter\docRoot\client

This resolved the issue in our enviorment.

I hope this helps some people resolve the same thing...

[beovax]

I had this other day, tried all sorts restarting the VC adn VUM services etc etc

In the end I went into the VUM configuration settings and just changed the notification schedule. This killed all the outstanding queued tasks and the next one completed all OK. FIngers crossed this problem is now solved. It was getting very annoying with so many stuck in the task list

[allencrawford]

I've had this happen in our 4.1 environments as well.  It doesn't happen very often, but when it does, I'll see around 30 of these tasks queued up but they all error out as soon as I log into the server with the vSphere Client (w/VUM plugin enabled).  Just happened the other day actually.  It is almost like that "check new notifications" task can only be completed when someone with the VUM plugin enabled is connected to the vCenter/VUM server.  So when none of our admins are connected, it may be queuing up, but as soon as one of us connects and the next scheduled check hits, all the pending ones immediately error out and the latest check then works fine.  Weird.

[mark_chuman]

Check to make sure you have a 32bit DSN allocated for VUM.  If you did setup VUM on a 64bit DSN and don't have a 32bit DSN setup you would have VUM errors upon logging in though.  This combination could occur if you setup a 64bit DSN for VUM pre upgrade and then deleted the 32bit DSN post upgrade (ie, the upgrade install used the 32bit DSN and not the 64bit DSN).

[Threonine]

I'm getting this same issue.  Definitely agreed it resolves itself when you're logged in with a vSphere Client running the VUM plug-in.

This is what happens when you login with the vSphere client with the VUM plug-in.  Prior to that it just hangs indicating the task is queued.

I've confirmed the 32-bit system DSN is already setup.  I may have some authentication issues going on...  I'm going to be rebuilding this server shortly.  So we'll see if the problem recurs.

[wgbeatty]

For me, this was a simple but embarrasing fix.  Set up a new workstation for myself and had the VSphere Client installed.  Saw lots of these "check new notifications" messages in the Recent Tasks list and tried some of the suggestions such as restarting the VUM service with no success.  Then tried looking at the plug-ins and realized the Update Manager plug-in wasn't installed on my workstation...voila, problem solved :-)