The native application approval functionality within Microsoft Endpoint Configuration Manager, (which is still often referred to as SCCM, ConfigMgr, and Configuration Manager) originally only allowed defined admins to approve application requests from the Application Catalog and Software Center using the ConfigMgr administrator console. Starting with ConfigMgr 1810, you could also begin making pre-approved machine based requests with no user required, allowing you to install applications in real-time. Additionally, e-mails could be sent to a defined approver, or a list of approvers for each application that is deployed by entering e-mail addresses of each approver(s) into each application deployment at deployment type. This feature is coming along nicely. One thing that I often hear from customers regularly is “I want to have my users’ managers approve the applications, since they are going to ultimately be the ones responsible for covering the additional licensing costs out of their cost center.” Unfortunately, since you can only set one or more static e-mail address or DLs on each application deployment, this isn’t really possible today without having someone receive the e-mails, look up the requester’s manager, and manually forwarding them the ConfigMgr generated approval e-mail. This isn’t a very productive use of anyone’s time IMHO. As many of you know, I’ve been diving head-first into any and every chance to create PowerApps and Power Automate (Flows) to harness the power of these ultra powerful low-code/no-code application creation platforms. This small gap in ConfigMgr led me to come up with the following idea which may suit the need for many who are waiting for the application approval functionality in the ConfigMgr product to further mature. First, I had my customer make and choose an “Application approval” e-mail account to use. All applications requiring approval would be set to automatically e-mail this mailbox any time an...
-
-
September 28, 2019There are administrative activities that take place in every ConfigMgr/SCCM hierarchy that would be nice to be able to add some safety pre-checks before ConfigMgr takes off and does its thing. In the example I’m going to cover within, the scenario revolves around wanting to be notified when my ConfigMgr Automatic Deployment Rule (ADR) runs its usual scheduled download, distribution, and deployment process. I didn’t only want to know what is actually about to be deployed to my clients, but I want to know what the maximum runtimes are for each update, the start time and deadline of the deployment, some basic info about each update including a link to view more details and check for known issues, and any other interesting information you might want to include. You could opt to only be notified of the new software updates using status filter rules to run a script which sends an e-mail from within the script. I decided to leverage Microsoft Flow’s native Send Email capability to handle the notification e-mail. One great thing many don’t realize is that a free Flow plan is included with every Office 365 tenant. Once you realize all of the automation capabilities that Flow has, you’ll probably soon realize it’s worth bumping up to Flow Plan 1 so you can begin taking advantage of the Flow Gateway. Fortunately, it’s a great deal @ $15/user per month (with no limit to the number of Flows each user can create), or a per Flow plan starting at $500/month for up to 5 Flows. For more details on Flow and it’s pricing, click here. What if you want to take it to the next level, and not only be notified of the updates, but also click a link within the e-mail which allows you to review details...
-
Have you ever wished you automatically received an e-mail every time something specific happens in your ConfigMgr hierarchy, but you couldn’t find an alert or other notification option in the console? One way that many admins have accomplished this in the past is using a Status Filter Rule to run a PowerShell script which sends an e-mail to your SMTP server. This is great, but what if you want to do it expand the dynamics a bit and take other actions besides just sending an e-mail? If you haven’t yet had the chance to play with Microsoft Flow, I highly recommend checking it out. Another equivalent is called Logic Apps which are, for the most part, the same, however Flow is more geared to Office workers, business users, and Sharepoint admins, while Logic Apps has more advanced integration options available. At the end of the day, both will work for this purpose, so it’s ultimately up to you which you use, and if you know how to use one, you pretty much know how to use the other. Click here if you want to read more comparisons of the two. You get Flow free with Office 365, but if you want to hit Flow hard and plenty, you may eventually need a fancier slightly less than free version 🙂 First, browse to http://flow.microsoft.com Click My Flows, New, Automated from Blank. Enter a name for your flow in the Flow name blank. Give your new Flow a meaningful name Click Skip (you don’t need to select a trigger yet) In the search blank, enter Request and click on the Request trigger in the top window, and When a HTTP request is received in the Trigger window. In the Request Body JSON blank, enter your JSON code. In this example, we’re...
-
One bit of important information that can be a challenge to view in one easy-to-see location is what all is being inventoried during your Configuration Manager client’s hardware inventory cycle. You could certainly go into Administration –> Client Settings –> Default Client Settings –> Hardware Inventory –> Set Classes and export this to a MOF to view, but a MOF file isn’t in a nice, easy-to-read format IMHO. Another option you may decide to use is to launch PolicySpy.exe which is included in the Configuration Manager installation directory under Tools, and manually peruse through the various entries to see which properties are inventoried, one line at a time. A much better way that I personally prefer to use is to run a PowerShell command-line such as the following: gwmi –Namespace root\ccm\policy\machine\actualconfig –Class SMS_InventoryAgent_Policy | Select ItemClass, Properties | Sort-Object ItemClass | ConvertTo-HTML | Out-File C:\temp\test.html Of course you can save this html file to any path and filename by simply modifying the path and filename at the end. Once this runs, just double click the resulting .html file which it created, and you’ll see a nicely formatted and sorted list of WMI Classes and associated properties which are being inventoried on your clients. Of course you could use convertto-csv and out-file filename.csv instead of saving it to html, but that is totally up to you and your needs. This method of determining what all you’re inventorying in your hardware inventory on your clients seems very quick, easy, and as a bonus seems nicely formatted. I really hope you find it helpful! Until next time…
-
I once had request for a way to determine if a specific PKI certificate was installed on some Windows OS machines. To accomplish this task, I decided the easiest method would be to create a simple PowerShell script which would check for the existence of the certificate, and then use the infinitely powerful Compliance Settings feature of Configuration Manager to run the script and report back the results. While on the topic, I also decided to create a CI that checks for Server Authentication intended purpose PKI certificates that are about to expire in 90 days, so that someone can be alerted and hopefully avert an outage caused by an expired certificate. First, for finding machines with a specific certificate installed, here’s a snip of the details of a sample certificate I’m looking for. Notice in my example that the Issuer is “russrimmerman-DC1-CA”. You could check the certificates Issuer, Subject, expiration date, or any other property of choice, but in this example, I’m going to look for the Issuer. You have two options for running PowerShell scripts on clients, one is to sign the script with a trusted certificate, and the other is to set the PowerShell execution policy to “Bypass”. In my example, I won’t be signing my PowerShell script, so I will go into Administration->Client Settings and select the default or create a new Client Settings. Then go into the “Computer Agent” section of the client settings and set the PowerShell execution policy to “Bypass”. This allows unsigned PowerShell scripts to execute when executed by the ConfigMgr client. If you don’t use the default client settings, you’ll also need to make sure the custom client settings you created are also deployed to the collection you will be checking compliance on. Now, go to Assets and Compliance->Compliance Settings->Configuration Items...