Working with a customer recently we wanted to deploy a ConfigMgr Application to all all laptops in the organization without creating a new collection of just laptops. Using the ChassisTypes property of the Win32_SystemEnclosure WMI namespace is a great way to do this; however, it can get a bit complicated, especially when there is non-normalized data in the inventory. An example would be a wrongly coded ChassisType.
Additionally, if you want to target only desktops and exclude virtual computers the details can get tricky if you have a diverse environment.
The script Get-ChassisTypeName.vbs (no, it isn’t PowerShell… gasp!) will return IsLaptop, IsDesktop, IsServer, and IsVirtual based on the ChassisType and an array of computer model names. For example, every Dell OptiPlex is a desktop, regardless of what the ChassisTypes property returns. Determining IsVirtual in ConfigMgr is tricky because of some underlying issues. This script removes the confusion and gets the job done.
I recommend reading Brandon Linton’s ConfigMgr 2012 Chassis Type Global Condition blog for implementing this as a ConfigMgr Global Condition.
Global Conditions don’t work in a Task Sequence, but it would be trivial to add code to populate a custom TSVariable with the result. You can rely on the source script from MDT if your TS is MDT integrated, but it doesn’t handle the edge cases and it’s a ton of overhead just to determine the Chassis Type.
Grab the script from GitHub.
IsLaptop, IsDesktop, IsServer, and IsVirtual
This blog post will dig into some more depth on what’s really required to share dashboards in Azure from a user rights/security perspective. If you are interested in creating custom dashboards, integrating Log Analytics and customizing dashboards this previous blog post covers those topics. This blog post will discuss:
- Permissions required to share dashboards in Azure
- Changing who can see your shared dashboard
- Permissions required to see content on your dashboard
Sharing dashboards in Azure:
To share a dashboard and be able to add others to be able to share it must be an Owner on the subscription level. The graphic below shows the users tab when you do not have owner rights.
With owner rights on the subscription you have the new Add button shown below.
If you do not have at least contributor rights you will be unable to choose the subscription when trying to share a dashboard as shown in the screenshots below.
“Users who are owners or contributors are able to list, view, create, modify, or delete dashboards within the subscription. Users who are readers are able to list and view dashboards, but cannot modify or delete them. Users with reader access are able to make local edits to a published dashboard (such as, when troubleshooting an issue), but are not able to publish those changes back to the server. They will have the option to make a private copy of the dashboard for themselves” from https://docs.microsoft.com/en-us/azure/azure-portal/azure-portal-dashboard-share-access
Based on our testing, to allow a user to create their own dashboard and share it required Owner level permissions so that they were able to manage who else can view that dashboard. If the user only needs to be able to share the dashboard and not control who can view it contributor level is sufficient.
Changing who can see your shared dashboard:
Once you have shared a dashboard, use the “Unshare” option to change permissions on that dashboard.
Clicking on Unshare brings up a new view on the right side where you can now choose “Manage users”.
From this view you can add or remove users and roles.
Permissions required to display objects on a dashboard:
The following are the access permissions which we have seen for the objects on a dashboard:
- Reader rights in the OMS workspace (this is done in OMS)
- Contributor rights in Azure to Log Analytics
- Reader rights to the “mms-eus” resource group (IE: The resource group where the Log Analytics workspace is stored)
- Reader rights to the “dashboards” resource group (IE: The resource group where the dashboards are stored)
From a high level you need to have at least reader rights to any data that you are sharing on the dashboard (and anyone who needs to see those on the dashboard should need permissions well).
Summary: To effectively share and control who has access to your shared dashboard you need owner rights on the subscription. When you want to change who can see your shared dashboard use the “Unshare” option. Finally, you need at least reader rights to the OMS workspace, contributor rights in Azure to Log Analytics, and reader access to the dashboards resource group to view the various objects on your shared dashboard (if you are displaying Log Analytics content as an example).
Jason Sandy’s has a great blog explaining ConfigMgr Package/Program retry behavior including the Retry return/exit/error codes and how often the retry occurs. One bit of info missing from the blog that I couldn’t find anywhere else (documentation, forums, blogs, etc.) was how long or how many retry attempts will occur before ConfigMgr gives up.
The answer is… 1008 times! This equates to every 10 minutes for an entire week; however, if the computer is restarted, turned off, goes to sleep, etc. the duration will be extended.
To verify this I created a Package/Program that simply exited with an error code in the FailureRetry list. Something like
Monitoring the ConfigMgr Client Execution Manager log (execmgr.log) will show the sequence of events.
Here is a filtered archive of the log as well.
Program Exit Code 4 has been tried 1 times, will retry later execmgr 1/11/2018 2:30:56 PM 11212 (0x2BCC)
Program Exit Code 4 has been tried 2 times, will retry later execmgr 1/11/2018 2:40:57 PM 11212 (0x2BCC)
Program Exit Code 4 has been tried 3 times, will retry later execmgr 1/11/2018 2:50:57 PM 10972 (0x2ADC)
Program Exit Code 4 has been tried 4 times, will retry later execmgr 1/11/2018 3:00:58 PM 6320 (0x18B0)
Program Exit Code 4 has been tried 5 times, will retry later execmgr 1/11/2018 3:10:58 PM 9644 (0x25AC)
Program Exit Code 4 has been tried 6 times, will retry later execmgr 1/11/2018 3:20:59 PM 12792 (0x31F8)
Program Exit Code 4 has been tried 7 times, will retry later execmgr 1/11/2018 3:30:59 PM 3640 (0x0E38)
Program Exit Code 4 has been tried 8 times, will retry later execmgr 1/11/2018 3:40:59 PM 10372 (0x2884)
Program Exit Code 4 has been tried 9 times, will retry later execmgr 1/11/2018 3:51:00 PM 3640 (0x0E38)
Program Exit Code 4 has been tried 10 times, will retry later execmgr 1/11/2018 4:01:00 PM 11208 (0x2BC8)
Program Exit Code 4 has been tried 11 times, will retry later execmgr 1/11/2018 4:11:00 PM 10304 (0x2840)
Program Exit Code 4 has been tried 20 times, will retry later execmgr 1/11/2018 5:41:04 PM 7232 (0x1C40)
Program Exit Code 4 has been tried 30 times, will retry later execmgr 1/11/2018 9:40:30 PM 13020 (0x32DC)
Program Exit Code 4 has been tried 50 times, will retry later execmgr 1/12/2018 11:22:05 AM 12300 (0x300C)
Program Exit Code 4 has been tried 80 times, will retry later execmgr 1/12/2018 6:57:52 PM 12360 (0x3048)
Program Exit Code 4 has been tried 150 times, will retry later execmgr 1/13/2018 6:38:25 AM 10400 (0x28A0)
Program Exit Code 4 has been tried 200 times, will retry later execmgr 1/13/2018 2:58:47 PM 11076 (0x2B44)
Program Exit Code 4 has been tried 250 times, will retry later execmgr 1/13/2018 11:19:09 PM 7588 (0x1DA4)
Program Exit Code 4 has been tried 300 times, will retry later execmgr 1/14/2018 7:39:31 AM 10752 (0x2A0)
Program Exit Code 4 has been tried 400 times, will retry later execmgr 1/15/2018 12:20:17 AM 6132 (0x17F4)
Program Exit Code 4 has been tried 450 times, will retry later execmgr 1/15/2018 9:33:10 AM 7728 (0x1E30)
Program Exit Code 4 has been tried 500 times, will retry later execmgr 1/15/2018 10:42:39 PM 2464 (0x09A0)
Program Exit Code 4 has been tried 550 times, will retry later execmgr 1/16/2018 7:02:57 AM 8564 (0x2174)
Program Exit Code 4 has been tried 600 times, will retry later execmgr 1/16/2018 4:10:44 PM 2292 (0x08F4)
Program Exit Code 4 has been tried 650 times, will retry later execmgr 1/17/2018 2:35:55 AM 2284 (0x08EC)
Program Exit Code 4 has been tried 700 times, will retry later execmgr 1/17/2018 12:03:37 PM 2324 (0x0914)
Program Exit Code 4 has been tried 750 times, will retry later execmgr 1/17/2018 8:26:40 PM 7172 (0x1C04)
Program Exit Code 4 has been tried 800 times, will retry later execmgr 1/18/2018 4:01:25 PM 6420 (0x1914)
Program Exit Code 4 has been tried 850 times, will retry later execmgr 1/19/2018 12:05:56 PM 8136 (0x1FC8)
Program Exit Code 4 has been tried 900 times, will retry later execmgr 1/19/2018 9:20:29 PM 10880 (0x2A80)
Program Exit Code 4 has been tried 950 times, will retry later execmgr 1/20/2018 5:40:49 AM 8136 (0x1FC8)
Program Exit Code 4 has been tried 1000 times, will retry later execmgr 1/20/2018 2:01:08 PM 8136 (0x1FC8)
Program Exit Code 4 has been tried 1008 times, will retry later execmgr 1/20/2018 3:21:11 PM 10848 (0x2A60)
The maximum retry count has been reached for program Exit Code 4. This program will not retry. execmgr 1/20/2018 3:31:11 PM 2036 (0x07F4)
The progress can obviously be monitored through ConfigMgr Status Messages… all 2016+ of them!
While the retries are ongoing, the Deployment Status in the ConfigMgr console will show as In Progress but will eventually become an Error after the retries conclude.
Where is this information stored? Can it be changed?
The configuration values are stored in the CCM_SoftwareDistributionClientConfig WMI class within the rootccmPolicyMachine namespace. MSDN has some good info on it.
While the article details out the ExecutionFailureRetryErrorCodes it does not list the default value of the ExecutionFailureRetryCount.
A quick WMI query with PowerShell will expose that though.
Get-WMIObject -Namespace rootccmPolicyMachine -Class CCM_SoftwareDistributionClientConfig -Property CacheContentTimeout, CacheSpaceFailureRetryCount, CacheSpaceFailureRetryInterval, SuccessReturnCodes, RebootReturnCodes, ExecutionFailureRetryCount, ExecutionFailureRetryErrorCodes, ExecutionFailureRetryInterval | Format-List Cache*,Ex*,Reboot*,Success* $a = Get-WMIObject -Namespace rootccmPolicyMachine -Class CCM_SoftwareDistributionClientConfig -Property ExecutionFailureRetryErrorCodes | Select -ExpandProperty ExecutionFailureRetryErrorCodes; $a -join ','
Check out some of the other properties here. There may be a good reason to tweak content download timeouts or retries, and success & reboot return codes (like you can with Applications and Task Sequences).
I haven’t gotten around to changing these values yet and verifying they stick. It should be possible to change these for the entire ConfigMgr Site and for individual computers. Chris Nackers and an old MSDN article give a good starting point for injecting ConfigMgr Client Local Policies.
Happy Retry (times 1008!)