What's New With ConfigMgr's Client Notification Feature

With the release of Configuration Manager this month - ConfigMgr 1602, was the introduction of some new features within the console in regards to how an administrator can interact with a client.  This blog will look to explain these new features, how they work and where they’ve been developed from. 

Firstly, some background.  Way back when, ConfigMgr 2012 SP1 introduced a feature called "Client Notification".  This added an option on the right click context menu for a client or a collection that granted the administrator the ability to trigger a machine or user policy retrieval and evaluation cycle.  Admins may be forgiven for thinking that this is a “push” action to the client, as it’s actually a client initiated “pull” after the admin triggers it.  This is ConfigMgr after all – the client requests everything.  Quite simply, the client is notified to start an action normally controlled by a schedule.

This feature was designed in order for vital deployments to be sent to clients a lot quicker and to save them waiting for their computer policy retrieval cycle, set to every 60 minutes by default.  Scenarios this would help with would be a zero-day patch, an urgent anti-malware definition or some other kind of scripted fix that needed to go out to all clients very quickly.

I won’t go into details about the ins and outs of Client Notification, although you can read the Product Group’s original blog about the feature release here.  In a nutshell, clients communicate over TCP or HTTP every 15 minutes to confirm they’re still online.  Once an action is triggered using Client Notification, only clients that have reported back as “online” will be notified to begin an action.  This means that your infrastructure won’t be wasting resources trying to open up individual WMI connections to clients in order to trigger these actions.  Other tools that seem to perform these actions can be quite costly in terms of wasted resources, especially when targeting a large collection.    That’s why we would suggest using the out of the box tools whenever possible.

“But Ricky, sometimes I need to do more than just a policy retrieval on a group of computers and using other tools to perform this seems like the only way!” 

That’s a very good point, and the very reason that the list of actions that can be performed in the Client Notification has now been extended in the 1602 release.  Check it out…


You can see along with computer and user policy retrieval; we now have the ability to collect discovery data, start a hardware or software inventory cycle, evaluate any deployed applications, or start a software update deployment evaluation too.  As stated above, triggering any of these actions will see that only clients that have reported back in the last 15 minutes will be given the notification to begin the chosen action. 

One more feature that was introduced that takes advantage of the “keep-alive” message sent by clients every 15 minutes is being able to see if a client is online or not when viewing it in a collection.  Have a look…


The grey icon represents that the client is offline, and the green icon shows that the client’s keep-alive message has been received in the last 15 minutes.

I hope this helps explain this small feature introduction, which seems to have slipped under most admins’ radars.  Remember, if you have any suggestions about ConfigMgr, please log them at the UserVoice site and get those votes assigned to any other features you like the look of. 

As always, please leave any comments or questions below.


Comments (24)
  1. Question says:

    Hi Ricks, is there any verbose logging on the client notification channel? Have a lovely day.

  2. Ryan Ephgrave says:

    Because this uses client pull, could there be a 15 minute delay between when the action is triggered and when the action actually happens?

  3. rickysimpson says:

    Both excellent questions. In terms of logging, refer to the logs associated to Client Notification in the TechNet list. I’ve bookmarked it here for you.

    In regards to the time taken to perform the action, there’s no 15 minute delay applicable here. The notification server creates the required message and pushes it to all online clients at that time.

    There is a throttling mechanism in place that will stop the assigned management point from being overloaded with policy requests (for example). This value can be edited in the registry. Check the FAQ on the blog I linked in my post above for more information
    about the internals and how the feature works.

  4. JamieT says:

    So you can only run this against a collection?

  5. rickysimpson says:

    Not at all, I only used a collection scenario as an example. You can also target a specific machine within a collection view.

  6. Steve F says:

    Thanks Ricks. One final question please – does this work for internet based clients? Regards from Scotland.

  7. JamieT says:

    Thanks. I figured out what I was doing wrong. You can right click on a specific machine but you have to do it from within a collection. If you, at least when I right click a device in all devices I don't see that option for Client Notification.

  8. rickysimpson says:

    Hi Steve, I’ve not tested it on IB clients. Although, Client Notification is facilitated using the Management Point. So if I was a betting man, and as long as there is an Internet facing MP available, I’d say it would work. The proof would be to get up
    to 1602 and see if your Internet based clients show as being "online" in the console with the green icon. Regards from Scotland also 🙂

  9. dj says:

    Yes, it will work for an IB client, as long as the client can connect to the MP. This is one reason the BGB protocol is client side to MP initiated, is then it can navigate through NATs and Proxies from the client to the MP. The MP cannot reverse navigate
    back through NATs/Proxies not to mention firewalls. So by connecting from client -> MP it solved many network challenges.

  10. dj says:

    and the 15 minutes is never a 15 minute delay, or polling cycle. It is that every 15 min (or 5 min depending on tcp vs. http); a keep-alive message is sent from the client to MP on the network protocol. If the MP doesn't receive this within timeout; then
    it assumes the client may have suddenly been disconnected or shutdown – and will close the connection – treating the client as offline until it hears from the client again. But all communication from the MP -> client is immediate if the connection hasn't timed

  11. Robert Yoke says:

    Hi Rickey, this is an excellent blog post, very informative and I was not aware of this feature. It is much better than running custom scripts to force the action on the client. Please can you tell me what is the impact on running this on a collection
    with more than 5000 clients in it? Will the MP processing the notification be under any sort of strain? Could you provide some performance benchmarks on the overhead of this? Thank you again Rickey. -RobertY

  12. rickysimpson says:

    Hi Robert. Thanks for your comment. Please hit the 5 star button if you like it 🙂

    Here is a quote from the Product Group’s FAQ section on the feature –

    "Question: Will an MP be overloaded by triggering download machine policy?

    Answer: Notification server implements the push throttling mechanism. Default value is notifying 42 clients per second. So the load added on MP is controlled. You can configure the value thru registry HKEY_LOCAL_MACHINESOFTWAREMicrosoftSMSNotificationServerTask
    Throttle Param. However, it is still not recommended to target this action to large collections(ex. All Systems) except under extreme circumstances that warrant it."

    I hope this helps to answer your question.


  13. Robert Yoke says:

    Thank you Ricky for such fast replying. If you have any performance test data that would be meaningful as well. I have two more questions if you can please assist me further:

    1. Does this work for Linux and Mac clients? Especially we are managing many Linux servers for our websites.
    2. Any plans to expand the list of client notification actions to include all the available actions that the thick client offers from the actions tab?
    3. There was a blog post about the client cache sometime ago which they said it would follow up with a second part. Do you know when the second part would be posted? It would be interesting and helpful.

    Thanks again Rickey. -RobertY

  14. rickysimpson says:

    You’re welcome 🙂

    1. Client Notification works on Windows and Windows Embedded clients only.

    2. A lowly engineer like me can’t guess what the Product Group have in store for ConfigMgr 🙂 If there’s something you’d really like, go to the UserVoice page I linked to in the blog, and get your views heard. You never know, if enough people vote for your
    idea, it may be accepted.

    3. I’ve had a look and the engineer who wrote that blog left MS not long after publishing that article. I’ll make a note for one of the others guys to have a look and see what we can come up with.

  15. Robert Yoke says:

    Thanks Rickey.

    Really helpful and good information to all my questions. One final question of all the questions then I will stop taking your precious time – we have many machines using power down agent at night. I am worried about MP overload when they automatically turn
    on in the morning. If all machines turn on in morning at same time, do they all straight away connect to MP and if notification starts I could easily overload the MP? In one location we have over 3000 devices managed by SCCM which turn on around same time.
    Will they all send to the MP the notification heartbeat at the same time? So you probably now understand my reason for wanting performance infos.

    Do not put yourself down as lowly, you are a great SCCM admin! I hope to watch you talking one day on Ignite or TechEd! Have a great day Rickey! Thank you again! -RobertY

  16. rickysimpson says:

    I wouldn’t worry about performance in that scenario. One management point can look after 25,000 clients, so taking care of 3,000 starting up at the same time should be well within the capabilities of the MP as long as it’s hitting the minimum specs published
    on TechNet.

    If you want to look to see how quickly these tiny messages are processed, have a look in inboxesbgb.box. That’s where the files are processed from after they’ve been sent back from the client. You should see your MP clear them out relatively quickly.

    Also, if you feel performance is an issue at particular times, spin up another management point for that location and use the management point affinity feature to make sure only clients from that physical location use the MP (or MPs) in question. If you have
    more than one MP available, the clients will split themselves up equally over the available MPs.

    Some trivia for you too; a lot of the Client Notification internals have "BGB" in their labels. This is due to the feature originally being coded as the Big Green Button 🙂

  17. Guarav says:

    Dear rickysimpson
    Please tell me if you know if there is still problems with bgb inbox getting ful when using SQL Server replica on the managment point? We have a few very big clients using replica on MP and it had some issues in past as I remember was a technet article about
    it. Did you know if any hotfix is needed or not to avoid it in the future? Really nice bog post please try to do more as updates on this page are quite slow about sms and is alot of good infos.
    Warm regardz, Guarav

  18. rickysimpson says:

    Hi Guarav,

    I’ve seen in another blog that this isn’t down to a problem with the product, but more the way the database replica is set up. Doing things incorrectly can provoke this issue. Take a read of this…


    This explains why the problem happens and what can be done to fix it. You can obviously ignore the suggestion to use the primary site database 🙂 Concentrate on the steps that explain how to configure the DB replica correctly. Good luck!


  19. Guarav says:

    Thanks Ricky. Like Ricky from favorite UK show Eastenders? 🙂 This is exactly the blog I Was trying to find myself.

    One suggestion from mine would be a useful is a blog post on using a SQL replica, if that is in your skillset. I also agree with Robert Yoke that client cache part II would be greatful.
    Finally, perhaps you could share us an easter egg on why the name changed from Big Green Button? Cheers!

  20. rickysimpson says:

    I’m actually due to move out of the PFE team soon to start a new role within Microsoft, but I’ll leave those suggestions with the guys before I depart. 🙂

    As for the BGB – in my opinion, I think they didn’t want admins seeing it as a "Deployment Button" for everything. Client Notification should only be used for emergency deployments, not as the standard deployment technique for everything. That’s my view on
    it anyway.

  21. Robert Yoke says:

    Bad news Rickey. I wish you well in your new job, you are very helpful and I was looking forward to more blogs from yourself. I hope our swords will cross again one day. -RobertY

  22. Ian D says:

    Very informative, I'd not seen this! Good luck in your new role.

  23. anonymouscommenter says:

    For the one who are still not on 1602 level, check this out :

  24. Brian Combs says:

    Has anyone experienced Client Notification suddenly not working properly on sporadic clients? I’m seeing an issue at 1610 where some clients that are online with healthy agents are showing offline in the console. There doesn’t seem to be any great troubleshooting methods. In checking on this issue I’m seeing “ERROR: Expecting more data from client” in the bgbserver.log file. This function was working great recently.

Comments are closed.

Skip to main content