A few months ago, I wrote a post about troubleshooting desktop analytics as I had come across an issue getting it set up and the troubleshooting available was little and far between. After working with an outstanding support representative from Microsoft, we discovered that my issue was rooted in poor group policy decisions that we made 2 years ago related to sending telemetry to Microsoft. These group policies were rooted in not only machine settings but also user settings.
For some time now, I've been hearing Desktop Analytics will provide some excellent data for your environment to assist with planning and deploying for your next Windows 10 feature update. And from the demos that I have seen, especially at MMS Jazz Edition, I believe it. The other thing I've been told multiple times over is that it's easy to set up. Just a few clicks and then wait a little bit and you have data. That's awesome! And I'm sure it is easy to set up, except.......when it isn't easy and doesn't work like it should.
I'd been using RegKeyToMof for the first time in a while in the last few months and thought some of us may want a deeper dive into how it works. I'm not going to cover directly on how to use it as Garth has covered that quite well over here: https://www.enhansoft.com/how-to-use-regkeytomof-2/
This post will be more on what it is doing. Hope you find it useful or interesting.
It comes up all the time when I want to know if anything in AD is not listed in CM and has a client, etc. If you work for an organization that is blessed with having excellent asset management, you could compare CM directly against your CMDB. But, everyone is not this blessed as it turns out. And reality being, you really should compare everything in AD to everything in CM. If its a domain joined computer, you'll probably want to know if it is or is not being managed by CM.
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.