SCORCH - Don't Get Burned!

Remember last year when Microsoft changed its licensing model for System Center as a whole? Evidently, things are still not quite as clear as we thought. I know our user group had Microsoft folks tell us that if you had CM07 with SA, that you would now own the System Center Suite. And the suite included CM, SCOM, SCORCH, etc.

But it's not as simple as that.

Microsoft put out some pretty detailed information like this link:

Key to this document was that it really made clear how much easier it was to license servers managed by CM. It's what they call Server Management License (ML). And it entitles you to run SCOM to monitor your CM servers, for example (no licenses are needed beyond the one for the server SCOM would run on.)

What is rather gray here is how you can use SCOM to monitor your CM servers without issue, but you cannot use SCORCH so easily. I'm now being told that a license for SCORCH (via the SC Client Management Suite or the Enterprise CAL) is required for any desktop being managed indirectly via SCORCH's orchestration.


To be precise, SCORCH cannot be used to directly touch a PC - this makes sense just like SCOM licensing does (you'd expect to have to pay to use SCOM to directly manage PC services, for example). But Microsoft is making a new point that I've never heard of before regarding an indirect touch of desktops. They're now saying that because CM manages desktops, that we're indirectly talking to clients and are still responsible to pony up for an a license for all desktops in the CM database.

Examples of SCORCH use and licensing:

  • Optimize some SQL tables in CM, or to pull back a list of machines (even workstations) for reporting. This would be considered distant enough of a use of SCORCH to not require additional licensing.
  • Approve software in CM (recall the Application Approval Workflow?) or use SCORCH to add workstations to a collection. This would require additional licensing.

I know this new wrinkle could suddenly make any SCORCH work you've done so far put you on the hook for a lot of money.

If it helps, there will be a licensing session at MMS this year.

If you have any doubts about where you stand on this, I highly recommend you make this session.

  • Created on .

The MP Replica Doc

I love MP Replicas and have mentioned them before:

Well here is a document fellow CM MVP Kent Agerlund has written. It's in the lab format from the CM12 course he teaches (which I highly recommend). This document also shows how to configure the BGB service - recently renamed to Client Notification in SP1. While the MS online documentation is pretty good for setting this up, it still reads a bit muddy as they don't make it totally clear that in 99.999% of cases, the replica should go on the MP itself for the benefit of resiliency, not to yet another server in the mix that could go down and end client communications. This document shows how to put that replica on the MP itself.

Thanks to Kent for letting this document go public. Our hope is that it gets more people to start using replicas.

  • Created on .

Server 2012 OSD Issues in CM12 SP1

I just tried a CM12 SP1 TS to deploy Server 2012 (using MDT 2012 U1). I got the same error as listed here:;EN-US;2468097

Failed to load class properties and qualifiers for class BDD_UsePackage in task sequence

The same fix listed in the KB worked (wording is a tad different).

Unrelated, but also worth noting, last night while making my image, I tried to use the offline servicing to inject software updates into my Server 2012 image by clicking on Schedule Updates in the console. No updates show at all.

The provider log shows that CM is looking for Windows 8 Server instead of Windows Server 2012:

ExecQueryAsync: COMPLETE select * from SMS_UpdateCategoryInstance where LocalizedCategoryInstanceName like '%Windows 8 Server%'

Evidently, the fix should come in CU1 (no promises). Until then, just keep using the install updates step in a TS, I guess.

  • Created on .

Replacing server with CM07 running SQL12

We upgraded our CM07 production environment to SQL12 last year. We like SQL12 and I think I've mentioned before that we saw about a 10% improvement in performance. So yay!

But there is a downside we didn't consider.

This weekend, we replaced our old CM07 central site with a new server. To do that, you simply install CM on a new box and run the repair wizard. But we forgot that you cannot install old CM07 on top of SQL12, so we had to uninstall SQL12, install SQLR2 with SP1, install CM, stop\disable CM, uninstall SQLR2 (actually MS wants you to upgrade, but that's ugly), install SQL12, enable\start CM, then run the repair wizard.

What a pain.

Then the recovery failed because we didn't have our SQL files parked on the exact same drive letters. Part of the point of the new server was to get more drives, so we had to redo our SQL layout, then run repair to restore from backup, then stop CM and move files around again as we wanted them.

More pain.

Anyway, it should be worth the effort, but it would have saved us time had we known about these 2 issues in advance. So now you do - just in case.

  • Created on .

PS - I Love You

I'm no scripter by any means, but I sure know when they're nice to use vs. the CM console.  Here are some PowerShell scripts I'll demo at the AZ User Group.  One is for flipping all of my deployments from an empty collection (which my ADRs are set to target) to pilot, one from pilot to production, and one to flip back to empty.  Because I need lots of ADRs to download all the updates each month (blasted ADR filters!), I have lots of deployments created and they take forever to flip in the console and I could easily miss one.  So the scripts do it and work fast.  Note that there is probably some cooler way to write these, but who cares so long as it works.  The key to PowerShell is to get the job done.  I'm sure I'll get better with time.  Greg Ramsey got me going with these.

The other scripts I'm going to show were written by my teammate, Jeff Carreon.  He took my build doc for CM12 RTM on Server R2\SQL R2 and turned it all into PS.  Edit as needed for your own use.

  • Created on .

CM07 and SQL12: Pull the Triggers!

Yes, pull the trigger on installing SQL12 if you have CM07 as it's supported, but what I'm talking about pulling here are two useless triggers in your CM07 database; even if you didn't go to SQL12 yet.

What am I talking about? There are two redundant triggers in the CM07 database which I have disabled.

Add_Remove_Programs_64_ and dd_Remove_Programs_64_ do the exact same thing.
Virtual_Application_Packages_DATA_ins and _Application_Packages_DATA_ins do the exact same thing.

If you install KB2676776 it rewrites many things in the DB so that SQL12 doesn't choke on old syntax, but these 2 triggers don't get rewritten.

You could just delete them. And if you do, the cool thing is that the weekly indexing task (hopefully you have enabled that) will rewrite them using clean code that SQL12 doesn't hate. But because these triggers are just duplicates and the work is already being done, you might just as well disable them. I can't say if you'll see a performance boost or not (because it does seem to be a duplication of work).

My PFEs told me it was OK to go ahead and disable these until the day the CM team addresses them. To disable, just right click and choose disable. Yes, by all means, test in a lab 1st. So I last month, I disabled dd_Remove_Programs_64_ and _Application_Packages_DATA_ins and our logs have been error free.

  • Created on .
Copyright © 2019 - The Twin Cities Systems Management User Group