On several occasions at the local user group and at MMS, I have heard the discussion about wanting to have numbers in the task sequence steps that corresponds to the execution steps reported in the smsts.log file and those reported back to the ConfigMgr database (these are both the same numbering of course). There is also a user voice that exists for this very item and has been there for quite some time.
Its seems that getting away from Microsoft Deployment Toolkit (MDT) has been all the buzz lately. And really, for many of us, there is good reason to leave it behind. Garytown recently posted a great article about getting off of MDT, and the goods and bads of having it.
Here is my own version of a custom Gather script to handle this payload in VBScript.
Architecture = X64 IsOnBattery = True Model = Surface Book 2 UUID = 0FFFFFFF-DFFF-7777-0999-5E4FACEB00C5 Vendor = Microsoft Corporation Make = Microsoft Corporation IsVM = False VMPlatform = Memory = 16308 Product = Surface Book 2 SerialNumber = 002123456789 BIOSVersion = 389.2370.769 ..................and more..................
For part of our upgrade process, we decided that we wanted to give users the opportunity to complete a survey to give us their feedback on the upgrade process. We thought of an email but, figured that would be just as well ignored as any other bulk email. So, I thought we could just dump something in the run once, or startup for the user that initiated the upgrade. So, the first thing I needed to do was capture the user to a task sequence variable. Sounds easy but, remember, the task sequence runs as system.
My coworker and I have recently had a little bit of fun with status messages, using them to trigger emails and other alerts to admins etc. In playing with them, I was curious on just how many there were, or could be rather. I then stumbled across this technet gallery post. So, yes you can do whatever you are trying to track and view all status messages that are sent to CM but, this may be useful in helping narrow that down ahead of time.
So, here we go.
For those that have used RegKeyToMof to create custom inventory MOF files to inventory registry keys, or export a mof from one environment and import them into another know that it is a fairly easy to do process. I have now seen on a few occasions now where the MOF file fails to import. No matter what you do, it will not import. You receive the following error:
With how easy it is to upgrade Configuration Manager now, it can be easy to forget about the most important component of your CM infrastructure, SQL. I'm guessing that a number of us are still running SQL 2012. Why? Because when we built our CM 2012 environment, that's what was the latest for SQL at the time. So, a number of CM environments are still running 2012.
Administration of Configuration Manager is more than a full-time job by itself. Maintaining some sort of documentation for the environment that can be given to management or stored internally can be an all together second job. So, why continue a manual task of creating documentation when you could automate it and have an extensive and detailed document created in minutes instead of hours.
