Random SCCM 2012 Tips #1

So while I was upgrading a client site to SP2 we ran into some random glitches that I thought I’d share as tips.  Hopefully you find them useful.

1. Preinst.exe /stopsite - useful to stop all services for SCCM right before you do a final SQL backup before starting an update.  Can be found in the program install directory of SCCM (<SiteServerName>\SMS_<SiteCode>\bin\X64\00000409).
2. The compression on a SQL backup is amazing.  I've heard it can compress with dramatic results but I've usually only dealt with uncompressed backups.  When dealing with a large database or low storage (both scenarios I was experiencing at once), finding a free 120+ GB of free space can be a bit troublesome.  Watching SQL compress your 120+ GB database down to a mere 25 GB definitely gives a shocked face to most IT people.
3. When you finish updating a site that has numerous sites don't be surprised to see all links go “Link Degraded”  under “Monitoring -- Database Replication” after the update.  You very well might have a handful of slower sites report “Link has Failed” as well.  Let it sit and just keep an eye on your replication logs (rcmctrl.log and replmgr.log).  You'll hopefully see lots of traffic and, depending on speeds, you’ll hopefully see sites start to change back to “Link Active” between 15-120 minutes.  Yup, I said 2 hours.  In the real world you very well might have a site in a 3rd world country with a 3 MB satellite link in the middle of a sand storm and it will possibly even take longer than 2 hours to show as active once the parent link starts re-initializing links after an update.
4. Keep a detailed eye on replication traffic from the SQL side.  Run the SQL query “exec spdiagdrs” and you'll be shown detailed info of the links as well as where they are at in the replication stages.
5. Also, if after multiple hours you sense that you do truly have a downed link make use of the “Replication Link Analyzer” in the SCCM console.  It's a handy utility that walks you through trying different steps as it tries to repair the link.  After running the utility, and hopefully it made some legit changes such as resetting the public keys or re-initializing the site data transfers, wait another 15-45 minutes and hopefully you'll be “Link Active”.
6. Always document a site before you start doing the work assigned.  Yes, to cover yourself in case of emergency but also to bring the puzzle pieces together to see if a piece fell into a wood chipper along the way.  Sometimes people are so busy just doing the job as quickly as possible that they forget about following standards, even just regular “cleanliness” routines.  It helps to have an assessment on hand to show those individuals, not as an attack of their work but as a reference to where inefficiencies exist.  You'll be surprised to see they are just as shocked as you that they've been mixing IP subnet, IP range, and AD site boundaries to the tune of over 750+ boundaries when they could have utilized AD sites and had SCCM automate the creation of all those boundaries (assuming their AD sites are accurate, your mileage may vary).
7. Ensure you check the box “Deploy this boot image from the PXE-enabled distribution point” on your boot WIMs or you won’t be booting.  In this case the client ensured the boot WIM was distributed successfully and all the appropriate NIC drivers were loaded into the boot WIM but every time they tried to PXE the “SMSPXE.log” reported “Could not find boot image…”.  Simply checking that box on their boot WIM and they were immediately able to PXE.  Sometimes its the simplest things that bite us.