Home » Skype for Business » Skype for Business–WatcherNode Gotchas

Skype for Business–WatcherNode Gotchas

Today I tackled SCOM Watchernode for Skype for Business server for the first time. You may be thinking why I have left it until now? Truth is I have done my very best to avoid it at all costs in the past and was often completed by a SCOM consultant anyway. However, being on site with a customer I decided to help them out and “give it a go”, as they say.

Turning to the usual resources for implementation pre-reqs, and method, aka TechNet and Google, I found numerous blog posts that walked you through setting up the Watchernode and SCOM management pack etc. So this blog is not going to reproduce other people’s hard work. Instead this blog post is intended to fill in the gaps where possible as following some guides tend to leave you scratching your head as to why it doesn’t work.

Gotcha #1

When creating your test service accounts to process synthetic transactions, ensure that you enable them for Skype for Business and assign the required user policies for conferencing, federation etc. Logical right? Once you have done this you should store their credentials i.e. sip address, username and password in the local credential store of the watchernode computer by running the following command for each of your test accounts using SfB Management Shell as an elevated administrator on the watchernode computer

Set-CsTestUserCredential -SipAddress "sip:test001@skype4b.uk" -UserName "sfbuk\test001" -Password P@ssw0rd
Without performing this, the synthetic transactions cannot be completed for user base tests.

Gotcha #2

When deploying the SCOM agent to all Skype for Business servers, make sure that you enable the agent to act as a proxy for other machines in SCOM management console as well, not just the watchernode computer. Make sure you reboot all Skype for Business servers once configured, not just restarting the monitoring agent service.

Also, in SCOM make sure you flush the health state cache on each agent to force the discovery scripts to reinitiate.

Gotcha #3

When running the New-CsWatcherNodeConfiguration commandlet, it is not clear as to where to run this. I assumed that running it on any server would be OK, but turns out that you need to run this directly on the watchernode computer using Skype for Business management shell. Still not convinced on this, but running Get-CsWatcherNodeConfiguration only returns the configuration when executed on the server that the New commandlet was run on. Before you suspect replication, Get-CsManagementStoreReplicationStatus commandlet returned all servers as TRUE even after an manual invocation. Strange, but maybe this is by design…

Gotcha #4

Make sure that you add the watchernode computer account to the RTCUniversalReadOnlyAdmins security group, or the pool health will not be returned, once added the watchernode computer needs to be rebooted.

Using these gotchas, together with the guides and TechNet articles out there will allow you to successfully deploy a watchernode for Skype for Business.

Hope this helps.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: