Michael Griswold's SCCM Tips and Tricks

What was old is new again

Mike Griswold — Tue, 20 Nov 2018 19:44:25 GMT

The time has come for me to change blog platforms. I have tried to clone over many of my more popular or relevant posts to keep for future reference. I don't plan to do any more blog posting on this site. If you don't see your favorite but want to make sure it doesn't get lost, leave a comment on my new site. Speaking of which, here is where you can find any of my future ConfigMgr/SCCM blogs: https://learnconfigmgrintune.wordpress.com/

Don't forget the provider!!!

Mike Griswold — Fri, 19 Oct 2018 19:50:19 GMT

I have seen across the internet where folks have been frustrated, unable to remove a site system that used to perform some role in SCCM. The prior role (DP, MP, etc.) was removed and now it only has two roles listed, "Component Server" and "Site System". When attempting to delete it you can't, because of the component server role still being listed. Restarting the SMS_SITE_COMPONENT_MANAGER is a suggested step to take to get the component server role to clear and allow the deletion, but in some cases that won't work. Why not? Well.., the component server role is there for good reason..., there is still an active ConfigMgr component on the box. Sure.. it no longer lists as a "site database server" or "management point" but it does have a function running on the machine. There is one role that does not display through this area of the UI...., the provider! To see what servers have the provider on them you need to navigate in the ConfigMgr Admin UI to \Administration\Overview\Site Configuration\Sites and bring up properties on the site that owns the site system. If that is your hold up, then it is time to run your ConfigMgr setup and move your provider to a new location.

Where are those files going?

Mike Griswold — Tue, 15 May 2018 21:36:12 GMT

When working with System Center Configuration Manager (a.k.a. SCCM or ConfigMgr) you see a lot of folders on primary sites where all kinds of files pass through. Most of these are text files and you can open with notepad. The hard part is knowing what the file does, and where it goes next. Most see these folders as their final place before loading the info into the DB and then the file deletes, but some files move elsewhere to process. I recently encountered an issue with a backlog of files on the CAS in hman.box. A lot can process through this folder, especially if you are connected ton Intune. In researching I found out an interesting piece of information I wanted to share. If you look at the file name you will see something like ABCUDXasdf234.MCM. This file name itself can tell you a lot. The first three letters are the site code of the destination for the file. In this example the file is headed for the ABC site. Once there the file will get renamed with the file extension of the next three letters, UDX in this example. Then you may need to do some sleuthing to figure out where it is headed. In my case I simply opened the file in notepad and got a clue, but if it wasn't that clear you could do some research on the file extension. In this example a UDX file is a user discovery file from Intune, so it is headed for DDM.box, specifically the ddm.box\userddrsonly folder.

Time for a Tune-up

Mike Griswold — Mon, 22 Jan 2018 18:52:47 GMT

Back in the day when I went on site to help SCCM customers all the time I kept a compiled list of tasks that should be done on a regular basis to keep their ConfigMgr hierarchy running well. I would share this with customers as appropriate and apparently it was handy because I was recently contacted by one of them who lost the list but was looking for it again. Rather than share to only that one customer I figured it would post it for all to enjoy. I will admit that I haven't updated this since 2015 so if you see anything new that is worthy of adding please use the comments below to share the knowledge and grow the community as well. I will add that much of this can be done through proper monitoring via SCOM, OMS, or other monitoring software. If so then your key task would be to make sure that monitoring is active and working correctly..., maybe cause a purposeful failure now and then and make sure your monitoring catches it. Daily: • Verify that predefined maintenance tasks scheduled to run daily are running successfully. • Check Configuration Manager site database status. • Check site server status. • Check Configuration Manager site system inboxes for backlogs. • Check site systems status. • Check client status. • Check the operating system event logs on site systems. • Check the SQL Server error log. • Check system performance. • Monitor software distribution and patch deployment status Weekly: • Verify that predefined maintenance tasks are running successfully. • Delete unnecessary files from site system inboxes. • Produce and distribute end-user reports if required. • Back up application, security, and system event logs and clear them. • Check the site database size and verify that there is enough available disk space on the site database server to allow the site database to grow. • Perform SQL Server database maintenance on the site database according to your SQL Server maintenance plan. • Check available disk space on all site systems. • Run disk defragmentation tools on all site systems that need it. • Reinstall clients via push to a collection of machines which are potentially unhealthy • Review client health reports and address any concerns. • Check compliance with desired configuration baselines * Check for any machiens needing aproval for communication with SCCM Periodically (Monthly/quarterly, etc.): • Review the security plan for any needed changes. • Change accounts and passwords if necessary according to your security plan. • Review the maintenance plan to verify that scheduled maintenance tasks are scheduled properly and effectively depending on configured site settings. • Review the Configuration Manager hierarchy design for any needed changes. • Check network performance to ensure changes have not been made that affect site operations. • Verify Active Directory settings affecting site operations have not changed. For example, you should ensure that subnets assigned to Active Directory sites used as boundaries have not changed. • Review the disaster recovery plan for any needed changes. • Perform a site recovery according to the disaster recovery plan in a test lab using a backup copy of the most recent backup snapshot • Check hardware for any errors or hardware updates available.

Dropping some FSP

Mike Griswold — Thu, 01 Jun 2017 14:37:59 GMT

(My post title is a nod to a Blues Traveler Song) As much as I know about the System Center Configuration Manager product there are always more things to learn, and sometimes older things as well. Recently I was doing some work regarding ConfigMgr Fallback Status Points (FSP). For those that don't know, FSP were originally designed as a way for clients who were doing HTTPS communication to the management points (MP) to have an unauthenticated method to say "hey.., my certs are bad" and alert the SCCM admin to the problem. Otherwise clients had no way to communicate their communication failure. FSP still tend to be a role that most folks don't think about or use, but for certain situations it can be highly useful. For example, when CCMEval runs and hits certain categories of issues it will send a message about client health back via FSP instead of MP. There is a behavior of the FSP that many may not know and it revolves around the HKLM\software\Microsoft\CCM\FSP registry keys. In here are two entries, HostName and IntranetHostName. An interesting piece of information is how these are used. In most cases the client will use the value in HostName when looking for the FSP. If that is empty or the server is unreachable then the client will attempt to use the server listed in IntranetHostName. If you have more than 1 FSP this might help you control and understand which clients will use which FSP. Now to end with a Blues Traveler quote, just for fun: "There's no such thing as a failure who keeps trying"

Quick provider overview

Mike Griswold — Thu, 20 Apr 2017 15:21:18 GMT

Nothing new in this post per se but I wanted to get something up and I recently became aware that this is not a fully understood area of the product. When you install an Admin console it has basic information as coded by the developers, combines that with the name or your primary site server, and BAM! The world of SCCM opens up for you as all the power and secrets of the ConfigMgr database are delivered to your fingertips. How does that happen? The System Center Configuration Manager administration console takes the name of the site server you typed in and connects out to WMI on that specified server. The developers coded it to specifically look for the \root\sms namespace and then check for instances of the SMS_ProviderLocation class. This is how it goes from a generically aware tool to a company specific installation awareness. Your actual ConfigMgr provider could be anywhere with any site code, and you could have multiple providers. The SMS_ProviderLocation will point to a specific server and the specific site code of your specific install, in the form of a WMI path like \\\root\sms\site_. In that namespace on that server is all the stuff that reveals your unique ConfigMgr environment to you.

WSUS in Azure

Mike Griswold — Thu, 06 Apr 2017 23:19:37 GMT

Recently I assisted in brining a new person into my team, Matt Garton. He comes from the world of phone queues here at Microsoft, which is where I had my roots and a lot of my foundational knowledge. He impressed me with his product knowledge and we brought him on. Once on-board I worked with him on some of our move to Azure plans and he worked out one of our pain points, which revolved around WSUS. On premise we have powerful SQL boxes that run our SQL DB and WSUS DB for each site (2 boxes in a cluster per site). We then have multiple WSUS servers for that site all pointing back to that same WSUS DB. Against best practice recommendations (for reasons I won't cover here, but for good reason) we put all the WSUS behind a high availability load balancer (HLB) that is a single "name" that we point our clients at. This gives resiliency and dependability to our WSUS usage for ConfigMgr clients. As we move our infrastructure to Azure and look at other changes to come back to best practice we didn't want an HLB. We also couldn't do a cluster in Azure and wanted to stick with as much "out of the box" stuff as we could. SQL 2016 has availability groups to meet needs like ours so we wanted to go that route. Apparently we were pushing boundaries because we had some issues with WSUS and had to involve some smart folks, like Matt, to get it figured out. Matt did most of the work and got it all pinned down then decided to share that knowledge with the rest of the world. Check out his post our team blog: https://blogs.technet.microsoft.com/system_center_in_action/2017/03/30/moving-the-wsus-database-to-sql-always-on/

Me... in two places!

Mike Griswold — Mon, 27 Mar 2017 15:01:45 GMT

Hi all, Sorry this blog has been quiet lately. I was asked to help get blogging restarted in my new team and that ended up being more time consuming than I had expected. I think we have the kinks worked out. I just put up the first post to restart my team's blog (https://blogs.technet.microsoft.com/system_center_in_action). While that post was written by me (and edited/reviewed by many) you shouldn't worry, they won't all be posts from me. I'll still try to keep making some personal insights and inputs here, although perhaps less frequently. I and my team mates will be adding some posts over at the other site. I'm excited by a few of the things we have lined up and hope that they are useful to you internet folks. Check it out, bookmark it, and keep an eye on it. https://blogs.technet.microsoft.com/system_center_in_action/2017/03/27/how-we-do-it-using-configmgr-and-intune-at-microsoft/

Why are old AD records still being discovered

Mike Griswold — Mon, 26 Sep 2016 20:17:22 GMT

Sometimes SCCM can be sneaky. For those that have been using Configuration Manager for a while now there are stories about surprises of one kind or another. I hit upon one of those recently. In my current role I'm in charge of client health and the issue brought to me was a large amount of discovered machines which, on investigation, didn't truly exist. The records were for machines that existed in AD but had gone offline..., they no longer existed and were not longer connected to the network. Our AD system discovery has settings to deal with dirty AD problems and filter our records older than DD days when doing the system discovery. The first check was to look at that and confirm it was set and functioning correctly, which it was. The catch was in GROUP discovery. Many folks don't realize this but Active Directory Group Discovery will make simple DDR for the members of the groups it finds. Here is the blurb from TechNet (https://technet.microsoft.com/en-us/library/gg712308.aspx#BKMK_ADGroupDisc)

Limited information about a groups member computers and users, even when those computers and users have not previously been discovered by another discovery method

Group discovery has the same AD filters on it as system discovery, but those had not been checked to turn on. Once checked... those old ConfigMgr records started cleaning out. :-)

Closer to the action

Mike Griswold — Thu, 21 Jul 2016 16:30:14 GMT

This blog may be quiet for a little bit. For those who follow it you know I was a Premier Field Engineer (PFE) at Microsoft. I have elected to take on a new role and I am joining the ConfigMgr product group to help with the deployment of new product functionality and features to Microsoft internal folks. Being part of the SCCM product team I will get to know the changes better, and earlier. I will have to be cautious in what I share but as I adjust to my new role I hope to be able to give more insights into the new stuff as it comes along. Stay tuned and know that I will try and keep spreading knowledge to help all the SCCM customers out there.