Today I was taking advantage of the quiet days between Christmas and New Years eve to do some overdue patching and updates on our Skype for Business 2015 servers. As the blog post title suggests the update would not complete successfully. Keep reading to see my notes on the subject.
The update itself was run by the instructions available on Microsoft’s support site, https://support.microsoft.com/en-us/kb/3061064.
The update installer will return an error stating that the installation has failed for some of the components, and both from the GUI windows as well as the log file linked to in the error message you will see that it is the Server.msp – or the Skype for Business 2015 server component that is failing.
Parsing through the log file did not leave any particular information as to why it had failed, besides “Reconfiguration success or error status: 1603.”.
A quick search online returned a similar error code when running Skype server update (http://terenceluk.blogspot.no/2016/02/unable-to-complete-installing-skype-for.html) and the blog post suggests that running the Deployment Wizard for the server modules would take care of the problem. As I tried to do so I only encountered another error, namely that the “Install-CsDatabase” cmdlet failed because of “insufficient space”. At the time I had about 15GB out of 72GB free space. Luckily we are running our enviroment on VMware so disk expansion is an easy operation. After this the update installer ran without problems.
Reviewing the logs (from the failed update) afterwards still had no reference to a space issue on the server, only some property info stating that “OutOfDiskSpace = 0” and some others – all with a trailing zero value. Not sure what to make of that.
The problem itself seems to be due to a check for disk space, where the requirement is stated to be a minimum of 32GB free space. For some reason I did not have the same problem on another server with 25GB of free disk space.
Rune's blog about things I see and UC 
Recommend extending system disk to 100Gb in order not to run into the same problem again 🙂
That’s what I did, hope it will suffice for some time.
My workaround was simply create an empty 40gb volume. The upgrade process will not use it anyway (it’s just an annoying check).
You can remove the volume immediate after the check or the setup will use the volume to create the replica folder 😦
I’ve ran into this problem before. 3 server enterprise pool, the first server patches nicely, then the second fails miserably. They both had 20gb free space. The solution (as you recommended), was to free up 32gb and try again. Works perfect after this! You might throw in a note that your IIS and CLS logs are usually good for at least a few gb’s if you’re struggling to come up with the space and you’re not virtual.
Thanks for the input. I believe in my case the problem is AlwaysOn Centralized Logging Service running (for troubleshooting purposes) and taking up a lot of space on the one Front End server – I did not have the same issue on the other servers in the pool.
Phew, you just saved me a couple of hours finding the REAL issue. Thanks a lot! 🙂