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.
Ricky
Comments
- Anonymous
March 29, 2016
Hi Ricks, is there any verbose logging on the client notification channel? Have a lovely day. - Anonymous
March 29, 2016
Because this uses client pull, could there be a 15 minute delay between when the action is triggered and when the action actually happens? - Anonymous
March 29, 2016
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.https://technet.microsoft.com/en-us/library/hh427342.aspx#BKMK_BGB
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. - Anonymous
March 29, 2016
So you can only run this against a collection? - Anonymous
March 29, 2016
Not at all, I only used a collection scenario as an example. You can also target a specific machine within a collection view. - Anonymous
March 29, 2016
Thanks Ricks. One final question please - does this work for internet based clients? Regards from Scotland. - Anonymous
March 29, 2016
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. - Anonymous
March 30, 2016
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 :-) - Anonymous
March 30, 2016
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. - Anonymous
March 30, 2016
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 out. - Anonymous
March 30, 2016
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 - Anonymous
March 30, 2016
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.
Ricky - Anonymous
March 30, 2016
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 - Anonymous
March 30, 2016
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. - Anonymous
March 30, 2016
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 - Anonymous
March 30, 2016
The comment has been removed - Anonymous
March 31, 2016
The comment has been removed - Anonymous
March 31, 2016
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...
http://blogs.technet.com/b/scotts-it-blog/archive/2014/09/29/incorrect-deployment-of-database-replica-in-sccm-2012-may-cause-client-fast-channel-notification-problems.aspx
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!
Ricky - Anonymous
March 31, 2016
The comment has been removed - Anonymous
March 31, 2016
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. - Anonymous
March 31, 2016
The comment has been removed - Anonymous
April 05, 2016
Very informative, I'd not seen this! Good luck in your new role.
Cheers. - Anonymous
April 19, 2016
For the one who are still not on 1602 level, check this out :
http://blogs.technet.com/b/manageabilityguys - Anonymous
July 11, 2017
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.