So far, we’ve just patched our backup pool… but we normally (even in the backup pool) drain all the Lync services on a front end (Stop-CSWindowsService -graceful -nowait) before applying a CU. This also helps prevent the need for a reboot of the server. We do the -nowait because we still (at least as of CU4) have issues with the response group call performance counter going haywire (like say, showing 1 billion active calls — I think it is actually due to a subtraction from zero). This inaccurate performance counter prevents the RTCRGS service from ever draining, so we usually give it a few minutes in this scenario and then stop it without -graceful.
Anyway, we noticed when running the updater for CU5, it applies an update to the Windows Fabric at the end. This update appears to unexpectedly start up all of the Lync server services on the front end, even if they were previously all stopped, and it seems to wait for them to be running before finishing the fabric patch. This restarting of services doesn’t allow us to plan for the timing of the restart or work in a desired reboot as in previous CUs. Also, we encountered one of the 4 FEs in this pool which actually required a reboot on the fabric update step, I believe because one of the services either started too early or didn’t start quick enough. In this case, I had to say “no” to the reboot, then drain the services again, so that then I could actually reboot without forcing the Lync services to shut down with the OS.
After doing all the FE’s I applied the database update. It appears that on a quick glance that rtcab and mgc are the only databases to change version numbers. I’ll be checking tomorrow to see if rtcab’s update reversed our ABSCONFIG custom settings, which has happened in past CUs.