And by looking in the log-file I saw this:
Failed to log in?
So the registration of the SSC server in the DB2 table fails and does not update the version number:
The version is still 188.8.131.52 in this table.
And if you try to upgrade the Community server after this, that upgrade will fail.
After checking the log-files, I noticed that the url the update-process is trying to access is:
http://SSCSERVER:9080/console/deployment/loginAnd when I tried this url in the browser, I got the message that
SPNEGO authentication is not enabled for your browserAHA!!
This means that the java process that´s trying to access the url has to be authenticated through SPNEGO in order for it to authenticate with the SSC server.
But, as far as I know, there is no way of enabling this for the update-process. It might be enabled in your browser, but that does not help the update-process.
So the solution is to disable SPNEGO for the SSC Deployment manager, sync the nodes and restart the SSC dmgr, SSC node and the SSC server.
And then you have to run the command manually:
c:\IBM\WebSphere\STSCServerCell\console\registerProduct.bat -upgradeVoila. The SSC version number is then upgraded in the DB2 table "Deployment"
And then the Community server will upgrade aswell. Phew!
In this document,
the Snoop servlet is installed on the SSC server, and then the url to the Snoop servlet is used in the Sametime Connect client to get the token so that you are automatically logged in in.
But is this really needed?
So in my environment, I deployed the Snoop servlet on the meeting server instead. SSO is then enabled on the meeting server, proxy server and the media manager. This is sufficient. The SSC does not need to have Spnego enabled, because you can configure the ST client to use the meeting server´s snoop servlet to get the token instead.
What I really would like to see is the authors of the document get together with Frank Altenburg and make a new, bulletproof Zero to Hero document combined on both their experiences :-)