Config Manager 2012 R2 SP1 and Ticker

Matt_Collins101

I am having issues with clients running delivered messages via the ConfigMgr Ticker application.  I am not seeing anything glaring in the site server (no CAS or secondary sites) logs that I can trace to the issue.  The message is created at the collection with Windows 7 workstations, the machines receive policy, but Cireson TickerApp.log on client always shows the following:

"Received a new Announcement, however this one is not targeted to this computer, ignoring"

Is there a simple explanation to what this error means or why the client determines the message is not meant for it?

I do see the following error in the BgbServer.log

"ERROR: The queue for BGB server doesn't exist."

Is this the stem of my issue? Any assistance that anybody can lend would be greatly appreciated.  I older thread with similar error but it seemed to indicated that BGB component had issues and failed setup.  I am not seeing that on my end.  Setup completes successfully but I do see the queue error repeat through out the log.

wally_mead

Hi Matt,

Sorry for the delay in getting to this, been pretty heads down on a new product we're working on (the Cireson Portal for Configuration Manager).

Anyway, if the announcement has made it to the client, that means that the "BGB Server" issue is not related. We use the BGB Server/Client interaction (or what is called the "fast client notification channel" to deliver messages from the server to clients. Just to verify, if you look at the bgbserver.log and see that it did create an announcement and delivered it, and then see it received in the CcmNotificationAgent.log, then that means all has happened as expected.

When I've seen that message before, it was due to the delivery of the Ticker message to users, and then the identification of the computers for that UDA relationship.

However, if you are delivering directly to a collection of clients (and not users), then I can't think of a reason why a receiving client in that collection would state that message. Can you attach the Ticker admin log as well as the Ticker Client logs for us to look at?

Thanks,

Wally

Matt_Collins101

Wally,

No reason to apologize.  Thank you so much for responding. 

We are not targeting users we are targeting computers. In this scenario the collection is based off of direct membership using the computer object.  We are implementing UDA however, and I am unsure if that causes an issue.  While I wait for your response I am just going to undo the UDA on these clients.

I have attached the logs you have requested

wally_mead

Hi Matt,

Implementing UDA would not have any affect on this process as long as you are targeting a device collection. It's only used if targeting users, so we know what computers to display the message on.

Have you tried the normal Configuration Manager fast client notification channel? For example, if you create any kind of policy update, such as a change to a client setting, and then go to the device collection, right-click, point to Client Notification, and click Download Computer Policy, does that push the policy down to the client immediately?

if that doesn't get the policy down to the client immediately, then our Ticker won't work either, as that is what we do to push our inventory policy down. You should be able to look at the CcmNotificationAgent.log on the client, and it should state that the client was able to connect to the server, that a handshake was successful, then very often sends a keep-alive message to the server.

Then when you do send a push notification from the console, it will show that in the bgbserver.log on the site server as well as a receipt of that same message ID in the CcmNotificationAgent.log. it could be that the firewall is blocking the port used for this. That's where I'd look next.

If all that looks great. then, try a new Ticker announcement to the device collection, and then send the four logs (two Ticker logs, plus bgbserver and ccmnotificationagent) and I'll take another look at it for you.

Thanks again,

Wally

Matt_Collins101

Wally,

Ok I think I see what is happening.  When your company first released this product last year I demoed it to some members of management here and they did not show interest.  At that time the application worked perfectly.  Fast forward a year and now management is bring the tool back up and of course its not working at all.   I did not consider to check 10123.  So it is my understanding in order for Fast Channel communication to work 10123 must be opened between client and management point or at least 10123 must be opened from the MP to the clients and clients can fail over to HTTP or HTTPS if they fail connection to MP over 10123.  Currently I am seeing that clients can connect to SCCM over 10123 but SCCM can not connect to clients on port 10123.

I need to talk to some guys here to see what thoughts are to allow the port from SCCM to all subnets.

I really appreciate your response.  Hopefully I can get this app working soon. 

Thanks!

Matt_Collins101

ok...So apparently I had a misunderstanding on how Client Notification actually worked.  This was not a port issue but rather a broker service issue for SQL.  Now that its corrected the ticker appears to be working which is great.  However, I am assuming there is a learning curve to deal with when dealing with time zones.  My site server is in CT and we have a portion of clients in EST.  EST test machines show that the client is expired when sending ticker as "Display Announcement as soon as possible".  I am guessing this has something to do with this having a 1 hour expiration and EST systems being ahead by an hour.  Is that correct?  Just thinking out loud trying to figure out how to send notifications to each time zone with out running into this issue.

Thanks again Wally

wally_mead

Great that you got it working, at least from the firewall issue point of view. And yes, I'd guess that we just put in the local time for the site server in the message, so if the client is in another time zone, that could be an issue. I'll bring it up with dev for the next rev of the product. To verify, don't use ASAP then, rather schedule it and give it enough time to accommodate you time zones.

That should give you a valid test then. Let me know, and if so, we can get that noted for a future update.

Matt_Collins101

Yes scheduling does work as expected.  So from what I see, since site server is in CT, scheduling start time one hour ahead of CT and then broadcasting to all gets the job done.  This is such a wonderful tool!

wally_mead

Fantastic, thanks Matt. I'll talk to dev to see if we can do anything to allow a configuration option for the admin to use the site server time, the local time of the client, or something like that. At worst case, we should make sure that we document it.

If you would be so kind as to mark one of the responses as answering the question, that way others who view this will know what took care of the issue for you in the event they hit it too.