Working around FedEx Delivery Manager's "system is currently unavailable please try again later"

Fedex has a Delivery Manager app that, if this post is any indication, they have no intention of ever fixing. If you're like me and in the unfortunate situation of trying to sign up for this particular garbage fire while getting the error "system is currently unavailable please try again later," read on for a workaround:

1. Use Internet Explorer. Yes, sorry. Internet Explorer. If you're on Windows 10, you have it, you just have to search for it.
2. Run through their signup process here
3. When you get the error message, hit submit again. If you get a new error saying that your username is taken, congratulations! You've won! Well, sort of.
4. Now log in to FedEx using the username and password you just created.
5. Click on your name in the upper right hand corner and select "My Profile"
6. In the lefthand column, select FedEx delivery manager, and then click Sign Up.

It's just that infuriating easy!

Lync Web Components Server update appears to freeze

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.