The Problem: On each Lync Server 2013 cumulative update round, the installation of Update for Web Components Server would get slower and slower. First it took 20 minutes, the next time it took an hour, then two, then it just seemed to go on forever.
The Investigation: Installation logs were no help - despite verbose .msi logging, I couldn't find anything obvious. No high CPU or disk usage by msiexec. Finally I installed Process Monitor.
Using Process Monitor, I could see that the installer process was going through the c:\windows\temp directory and reading old Lync command reports. I have a script that runs every hour and executes get-cscertificate to check for expiring or expired Lync certificates. What I didn't realize was that on each run it also outputs two logs files (get-cscertificate{guid}.html and get-cscertificate{guid}.xml) in c:\windows\temp.
My assumption is that the Web Components update package is written in such a way that it runs a get-cs* command and looks for the output in c:\windows\temp. At the time I was running in to this issue, I had ~700,000 .html and .xml files in c:\windows\temp. The installer seemed to be taking about 5 seconds per file, so there was potentially several years worth of delay happening at this point.
The Resolution:
1) Delete c:\windows\temp\get-cscertificate*.html and c:\windows\temp\get-cscertificate*.xml
This was the easiest part.
2) Stop my script from generating verbose reports.
If I needed them, I could have written a script that would run weekly and clear out older files, but I decided that I didn't need debug files for each script run. As such, I modified the line in my script that runs
get-cscertificate
to run
get-cscertificate -Report $null
After making this change and removing the files, install time dropped to about 30 seconds.
No comments:
Post a Comment