Customer wants to move entire datacenter into Azure. All of it. Nothing “on premises” whatsoever. Actually, not “wants”, but “insists, emphatically”. This includes file and print services, DHCP, DNS and WINS, and Active Directory. When informed about limitations with regards to network infrastructure (DHCP in particular), and shown proof-of-concept for print services, etc. they ask what can be done. The recommendation is to put some on-prem services to improve responsiveness, provide failover, etc. etc.. “But, we don’t want on-prem anything? You need to tell us how to make this work!”
Customer installs SCCM 2012 R2 on a physical server with undersized resources (memory, CPU, disk space, disk isolation, networking, yada yada yada) and installs SQL Server on a separate machine, where it coexists with about six (6) other instances. Performance sucks mud through a straw. We explain to customer the limitations on the SCCM/SQL licensing use-cases, and how it helps to collocate SCCM and SQL on the same host, AND that it can be virtualized for greater flexibility, etc.
Customer response “I know for certain that Microsoft DOES NOT virtualize SCCM!”
Customer sets SQL Server file auto-growth to 1 MB on all databases. Enough said. But they also have a maintenance plan that runs a DB shrink on all of the databases on the SCCM instance as well.
Contractor has to hire subcontractor to handle surge gap in staffing for an SCCM installation. Customer sets up work area in a conference room. Customer comes back a few hours later and finds subcontractor asleep with both feet on table, and two more laptops logged into other customer environments. Subcontractor is shown the door. However, not before having installed an entire CAS hierarchy using anti-best-practices methods which end up requiring an entire site rebuild months later. (Phil – I know you know who I’m talking about, but I can’t give any other hints)
Customer connects a third-party “asset management and help desk” application to SCCM by using a direct SQL connection. The app is configured to write back to the SCCM site through SQL. Shit starts imploding on day 1.
Customer needs to upgrade site with a remote Secondary site. Contractor remotes in and does the upgrade. After all is settled out, everything works fine. Next day, customer says all indicators have turned red in the console. Contractor remotes in and finds a ton of errors in site system logs on both ends, as well as Windows event logs on the Secondary. Most point to domain authentication issues.
- Contractor, “What changed since the day before?”
- Customer, “Nothing at all.”
- Contractor, “Are you sure?”
- Customer, long pause “Well, nothing besides the recovery”
- Contractor, “Recovery?”
- Customer, “The local tech said the CPU was running high so he reverted the VM to an earlier snapshot to fix it.”
- Contractor, long pause, “Ummm, ok. Well. Reverted to when?”
- Customer, “A snapshot from February.”
- Contractor, “It’s now September.” (this was when it occurred)
- Customer, “Is that a problem?”
- Silence followed by a very long inhale and slow exhale “Let’s start over, shall we?” …