Exchange Cluster Continuous Replication Failed

We had an Exchange 2007 Mailbox server's storage drive fill up due to log files not being cleaned out due to the backup job failing (don't ask). After we deleted the unnecessary log files and got the store back online, we weren't able to get its CCR passive node to bring 3 of the 5 stores online. We ran "Update-StorageGroupCopy -DeleteExistingFiles", and the process would complete. I would then show up as "healthy" with a "Get-StorageGroupCopyStatus" for a minute or so, and then fail. Checking the event log we got:

Event ID: 2059
Source: MSExchangeRepl
The log file 404149 for is missing on the production copy. Continuous replication for this storage group is blocked. If you removed the log file, please replace it. If the log is lost, the passive copy will need to be reseeded using the Update-StorageGroupCopy cmdlet in the Exchange Management Shell.

It wouldn't make sense straight away, as the database on the active node was "up to date" and shouldn't need those log files. After some research, I found that this was a result of the failed backup process. When we deleted the log files on the active node, we'd broken the replay log process (as we'd deleted log files that were created after the last time the database was backed up).

Given that we're using a backup solution that backs up the databases from the passive node, I had to use NTBackup Utility to do a normal backup on the database. Once this completed I was able to use the Update-StorageGroupCopy command to get the database replication back to a healthy state. In theory this process should work on a Standby Continuous Replication
SCR cluster as well.

Set Printer Share Comment to the Port Name

We use an asset tag naming system to target all of our printer ports to the physical printers. The queue names are abstracted from the actual printer it's self. All of the printers have a DNS name that is their asset tag plus the SCCM site code of the location that they're currently located in. The only problem with this is that it creates a bunch of extra clicking to determine what printer a queue is actually pointed to (okay, so its like 4 extra clicks to get the port name, but its still tedious). The work around we came up with is to set the comment tag on the printer to the port name of the printer. To do that we use the following bit of PowerShell code that runs on an hourly basis on the server. It was tested on Windows Server 2008, but should work just fine on Server 2003:

$printers = Get-WMIObject -Class "Win32_Printer" -NameSpace "root\cimv2" -computername "."
ForEach($printer in $printers){
$printer.Comment = $printer.PortName
$printer.Put()
}