ConfigMgr Inventory of Powershell Versions

If you happen to be curious about what versions of Powershell are installed/available on your clients, here's one way to pull out the information.  Note that the regkey locations for some of this information has changed from version 2 to higher versions, so it's completely possible that a future update to Powershell and the regkey location will change again; so if that happens a modification to these .mof files will be necessary.  As of Windows 8.1; these worked to report versions of Powershell installed.

Take the --> attached <-- and inside are two .mof files.  If you are ConfigMgr 2012, place the contents of the 'posh-configuration.mof.txt' at the bottom of your <inbox location>\clifiles.src \hinv\configuration.mof file.  In your configMgr 2012 console, in Client Settings, Default Agent Settings, Hardware Inventory, Classes... Import the 'posh-to-be-imported.mof'

Wait for clients to start reporting, once you get some clients reporting, the below sql query should get you started:

;with CTE as (
  select distinct resourceid
   ,RTRIM(substring(ISNULL((select ','+PSCompatibleVersion0  
        from v_GS_PowerShell0 p1
        where p1.ResourceID=t2.resourceid for XML path ('')),' '),2,2000)) as PSCompatibleVersions0
   ,RTRIM(substring(ISNULL((select ','+PowerShellVersion0
        from v_GS_PowerShell0 p1  where p1.ResourceID=t2.resourceid for XML path ('')),' '),2,2000)) as PowerShellVersions0
   ,RTRIM(substring(ISNULL((select ','+RuntimeVersion0
        from v_GS_PowerShell0 p1  where p1.ResourceID=t2.resourceid for XML path ('')),' '),2,2000)) as RunTimeVersions0
 from v_R_System t2
)
   select distinct sys1.netbios_name0 [ComputerName]
 ,cte.RunTimeVersions0 [RunTime Versions]
 ,cte.PSCompatibleVersions0 [PS Compatible Versions]
 ,cte.PowerShellVersions0 [PowerShell Versions]
 from v_R_System sys1
 left join CTE on cte.ResourceID=sys1.ResourceID

 

 

  • Created on .

MEMCM Keep a System Group active without re- Group Discovery

Background for context:

I happen to work at a large company, which has more than 300,000 employees. Using Enterprise Client Management (MEMCM), we often deploy 'free' Software to the majority of users (think something like Adobe Reader, or Google Chrome). This is so that as soon as <new employee> logs into a workstation, they can go to Software Center, and install software they might need to perform their job.

How we accomplish this is all new users are added to a group called (for purposes of this blog) "SC_All_Employees".
That domain group is (used to be, until this workaround) discovered using Group Discovery. If you are unfamiliar with group discovery, in your MEMCM console, Administration, Hierachy Configuration, Discovery Methods, Active Directory Group Discovery, and in Discovery Scopes, is a single rule for this: Group, I had browsed for the group name, and it resolved to
Distinguished Name: CN=SC_All_Employees,CN=CompanyGroups,DC=MyCompany,DC=ORG
GroupName = SC_All_Employees
GroupType = Security Group - Global

The collection query (WQL) is this (selecting Usergroups, not users, when creating the collection query)
Select SMS_R_UserGroup.ResourceID
from SMS_R_UserGroup
Where
SMS_R_UserGroup.Unique_UserGroup_Name0 = "MyCompany\\SC_All_Employees"

This results in there being ONE and only ONE resourceid in the collection, the resourceid for the Group, not the resource ids for the users who might be in that group. (This is important)

Why do we like use / use this? Because it's all then based on one single thing being updated--Active Directory. Add a user to the group, that user authenticates to Active Directory, and the token for that ad group membership is attached to that login, and CM can tell and use that group SID to check if they deserve any policies...Policies that for us, result in things being available in Software Center. It can literally be a minute between adding a user in AD, the users locks/unlocks their workstations, the user launches Software Center, and voila, the stuff is visible. It's wicked fast--to the end user.



The Dilemma:

As of ECM current branch 2006 (and it has been this way for decades), when one discovers groups which happen to be Security Groups, it is impossible to NOT discover the users inside the group. If you watch your ADsgdis.log on your primary site, you'll see it discover the group...and then within a few minutes discover all the users in that group. That's fine if your strategy for collection creation is to have a collection query like this:

Select SMS_R_User.Resourceid from SMS_R_User
where SMS_R_user.UserGroupName = "MyCompany\\SC_All_Employees"

That's limiting to USERS, not USERGROUPS.

However, that isn't what we at this large company need or desire. Having to do delta discovery and have CM create the user to group relationships is not ideal at our size. So we don't even WANT to record the User-to-Group relationships in CM. We want just and only the group, group SID, and that one, single resourceid.

When CM has to discover all 300,000+ users in that group, and create those relationships, it causes replication delays, and backlogs in ddr processing. It's a strain on the system for literally no reason we want to have.

So you think; so what; just have it discover the group once, and then turn it off, it'll be there forever right? Nope; by design there is a task for "Delete Aged Discovery Records". So let's say you have that set to 90 days. If you turn off discovery of the group "SC_All_Employees", in 91 days that resourceid will be removed (by design, and in general that is a good thing), and you have to re-discover it again.

There is a uservoice for this; so until they fix it, if this is happening to you, please vote it up.

https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/11096859-ad-group-discovery-discovering-group-members


The Totally Unsupported and Do Not Do It Workaround (so if you do this, it's not my fault, I told you not to do this).

In 2 labs, and then production, this worked, to "keep alive" a Group...once it was discovered once; and NOT have it be automatically removed after the period you have defined for "Delete Aged Discovery Records".

If you have ANY hesitation about this at ALL, don't do it. Don't even think about doing it. If you think you might want to do this anyway, do this in your LAB environment first. Don't have a lab? Make one. There are several guides on making a CM lab using virtual machines.

SO... you decided to do this anyway, even though I said it's unsupported, and <insert deity here> help you if you mess something up... you have a backup of your environment, right?


1) *do* take the replication hit, and DDR processing hit once, for the group "SC_All_Employees" (insert your own group here, whatever it is).
2) remove that rule from Group Discovery.

3) Query to look at what the values are "now" (before you do any testing).

DECLARE @RID BIGINT = (Select Resourceid from v_r_userGroup ug where ug.Unique_Usergroup_Name0 like '%SC_All_Employees')
Select U.ResourceID, U.Name0, U.Creation_Date, U.Windows_NT_Domain0 from v_r_usergroup u where [email protected]
Select * from DiscItemAgents dia where [email protected]
Select * from DiscItemAgents_Local dial where [email protected]
Select count(fcm.collectionid) as 'Count of Collections where this group is a member'
from v_fullCollectionMembership fcm where [email protected]

4) Set up a SQL job to "keep alive" that specific group. You see... deep in sql is where CM records which discovered resourceids should be marked for deletion at the next Delete Aged Discovery Records routine. This circumvents that process.... by cheating SQL into thinking it *has* been recently discovered; and not to cull it.

The SQL Job runs on your primary site Server (that has the SQL database CM_..., and did the Group Discovery in step 1 above).
We currently have it run twice daily (likely only needs to run maybe weekly, but I was testing this routine)
and run it in the cm_ database (when you set up the job, you have to say which database)

The sql inside that job is below; note the DECLARE @RID; make sure you put in your correct group.  This blog might also put 'smart quotes' around things, or have line breaks where I didn't mean to have line breaks.  Remember the above warning where I said don't do this if you have any reservations?  Yeah... be careful what you do. Also note the double single quotes ( ' ' ) ; that's because of the sql job needing the double single quotes. If you are going to run this interactively for testing, you may need to remove one of the single quotes in each instance.
You may want to run this interactively against your cm_... database, for testing before making it a recurring sql agent job.


--Get ResourceID, current utc time, groupname for the log, and the current value of DueForAgeOut
DECLARE @RID BIGINT = (Select Resourceid from v_r_userGroup ug where ug.Unique_Usergroup_Name0 like ''%SC_All_Employees'')
DECLARE @NOW DATETIME = GETUTCDATE()
DECLARE @SiteCode nvarchar(3) = (Select Right(db_name(),3))
DECLARE @GroupToUpdate nvarchar(80) = (Select Unique_UserGroup_Name0 from v_r_usergroup where [email protected])
DECLARE @CurrentDueForAgeOut int = (Select DueForAgeOut from DiscItemAgents where [email protected] and [email protected])

--Update the _local with current utc date, and log
UPDATE [DiscItemAgents_Local]
SET AgentTime = @NOW
Where ITEMKEY = @RID
DECLARE @VALUE nvarchar(max) = (@GroupToUpdate + '' has been updated to '' + CAST(@NOW as varchar) + '' in the DiscItemAgents_Local Table.'')
RAISERROR (@VALUE,1,1) with LOG

--Depending upon if it''s currently Null or not, set DiscItemAgents to either Null, or 0 if already not-0. Values possible
--are Null, 0, or 1. 1 is the value which triggers deleting the record when the task for Delete Aged DDR records runs.

IF @CurrentDueForAgeOut IS Null
BEGIN
UPDATE [DiscItemAgents]
Set DueForAgeOut = NULL
, AgentTime = @NOW
Where ITEMKEY = @RID and [email protected]

DECLARE @VALUE2 nvarchar(max) = (@GroupToUpdate + '' has been updated in the DiscItemAgents Table with these values ''+ CAST(@NOW as varchar) + '', DueForAgeOut to NULL.'')
RAISERROR (@VALUE2,1,1) with LOG
END
ELSE
BEGIN
UPDATE [DiscItemAgents]
Set DueForAgeOut = 0
, AgentTime = @NOW
Where ITEMKEY = @RID and [email protected]

DECLARE @VALUE3 nvarchar(max) = (@GroupToUpdate + '' has been updated in the DiscItemAgents Table with these values ''+ CAST(@NOW as varchar) + '', DueForAgeOut to 0.'')
RAISERROR (@VALUE3,1,1) with LOG
END

 


5) Monitor the job's success by looking at your SQL logs (Using SQL Server Management Studio (SSMS), connect to your primary site server that houses your cm_ database, go to +Management, +SQL Server Logs, then double-click "Current", if you have the above running successfully, you'll see entries similar to this (the group name, and time will be different for your environment:

MyDomain\SC_All_Employees has been updated in the discItemAgents Table with these values Jan 25 2021 5:35PM, DueForAgeOut to Null
MyDomain\SC_All_Employees has been updated to Jan 25 2021 5:35PM in the DiscItemAgents_Local Table


6) PARANOIA STEPS

Make yourself reminders to check these; and confirm it's keeping it alive:

DECLARE @RID BIGINT = (Select Resourceid from v_r_userGroup ug where ug.Unique_Usergroup_Name0 like '%SC_All_Employees')
Select U.ResourceID, U.Name0, U.Creation_Date, U.Windows_NT_Domain0 from v_r_usergroup u where [email protected]
Select * from DiscItemAgents dia where [email protected]
Select * from DiscItemAgents_Local dial where [email protected]
Select count(fcm.collectionid) as 'Count of Collections where this group is a member'
from v_fullCollectionMembership fcm where [email protected]

What means a problem has happened?
If the group is just plain gone, and the 'Count of Collections where this group is a member' = 0

That means something deleted that group--whether it was a human literally going into the console, right-click and delete the group (oops!!!) or the Delete Aged Discovery Records cleared it out, you then have to decide... do you still need that group; or was it retired on purpose? If not retired on purpose, most likely you'll have to re-take the DDR hit, by re-discovering the group again in Group Discovery, and wait for your DDR backlog and/or replication backlog to clear after that; and check this routine works.

7) What if the Uservoice is addressed in a future version, and there is a way to NOT discover the members inside a security group?
- If so, create the Group Discovery for this group, and do whatever the guidance is to say "just the group please, not the members inside the group"
- Disable this sql Agent job--you don't need to run it ever again, if ECM Current Branch has it natively.  Could probably also just delete the sql job completely, if the product has it natively.

 

CMCB

  • Created on .

Application Deployment options for all App Deployments

Have you ever wondered if you could get a report of all your Application Deployments' options?  The ones which are in the GUI for things like "User Experience, Show a dialog window instead of a toast", or "Deployment Settings, Send wake-up packets".  No?  Well, I did.  So with the help of my good friend John Nelson, attached is the SQL to accomplish that.  Below is a (very badly displayed, sorry) results of a query in my lab--where I only have two fake test deployments, where I was testing that all the values were getting reported properly.  "It works in my lab".

Attached --> here <-- is the .sql itself, or it's below.  In theory, I thought this would be helpful for finding if you wanted to be sure everything was designed to "show the popup diag instead of toast"--you could easily filter and sort and see what deployments might not have a setting you wanted it to have.

--###############################################
--Cleanup any accidentally left behind Temp Tables
--###############################################

 

If(OBJECT_ID('tempdb..#TempDeplInfoBase') Is Not Null)
Begin
 Drop Table #TempDeplInfoBase
End

 

create table #TempDeplInfoBase(
AssignmentID int,
Assignment_UniqueID nvarchar(max),
AssignmentEnabled int,
AssignmentName nvarchar(max),
CollectionName nvarchar(max),
CollectionID nvarchar(8),
InstallorUninstall nvarchar(25),
OptionalOrRequired nvarchar(25),
WOLEnabled int,
DPLocality int,
StartTime DateTime,
EnforcementDeadline DateTime,
TimeType nvarchar(25),
SoftDeadline int,
OverrideServiceWindows int,
RebootOutsideOfServiceWindows int,
WriteFilter int,
RandomizationEnabled int,
RandomizationMinutes int,
UseBranchCache int,
EnableMomAlerts int,
RaiseMomAlertsOnFailure int,
NotifyUser nvarchar(100),
PreDeploy int,
CloseDefinedRunningExes int,
AllowRepair int,
UseDialogNotToast int
)

 

INSERT INTO #TempDeplInfoBase (assignmentid,Assignment_UniqueID,AssignmentEnabled,AssignmentName,CollectionName,CollectionID,InstallorUninstall,OptionalOrRequired,WOLEnabled,
DPLocality,StartTime,EnforcementDeadline,TimeType,SoftDeadline,OverrideServiceWindows,RebootOutsideOfServiceWindows,WriteFilter,RandomizationEnabled,
RandomizationMinutes,UseBranchCache,EnableMomAlerts,RaiseMomAlertsOnFailure,NotifyUser,Predeploy,CloseDefinedRunningExes,AllowRepair,UseDialogNotToast)

 

Select
c.AssignmentID,
c.Assignment_UniqueID,
c.AssignmentEnabled,
c.AssignmentName,
c.CollectionName,
c.collectionid,
Case when c.DesiredConfigType = 1 then 'Install'
  when c.DesiredConfigType = 2 then 'Uninstall'
 else cast(c.DesiredConfigType as nvarchar)
end as 'InstallOrUninstall',
case when c.OfferTypeID = 2 then 'Available'
 when c.OfferTypeID = 0 then 'Required'
 else cast(C.OfferTypeID as nvarchar)
end as 'OptionalOrRequired',
c.WOLEnabled as 'Send Wake-up Packets',
Case when c.DPLocality > 80 then 1 else 0 end as 'Allow clients on a metered connection to dl content after deadline',
c.StartTime,
c.EnforcementDeadline,
case when c.UseGMTTimes=0 then 'Client Local Time' Else 'UTC Time' end as 'TimeType',
c.SoftDeadlineEnabled as 'Delay enforcement per user preferences, up to the grace period',
c.OverrideServiceWindows as 'Override Maintenance Window, for Installation',
c.RebootOutsideOfServiceWindows as 'Override Maintenance Window, for System Restart',
c.PersistOnWriteFilterDevices as 'write-filter handling, Commit Changes at deadline for Windows Embedded devices',
c.RandomizationEnabled,
c.RandomizationMinutes,
c.UseBranchCache,
c.DisableMomAlerts as 'Enable SCOM MM',
c.RaiseMomAlertsOnFailure as 'Generate SCOM Alert when failure',
case
 when c.NotifyUser=1 and c.UserUIExperience=1 and (32 & c.OfferFlags) = 32 then 'Use Dialog to NotifyUser at Available, and notify for reboot post-install'
 when c.NotifyUser=1 and c.UserUIExperience=1 and (32 & c.OfferFlags) <> 32 then 'Use Toast to NotifyUser at Available, and notify for reboot post-install'
 when c.NotifyUser=0 and c.UserUIExperience=1 then 'Suppress User at Available, notify if reboot post-install'
 when c.NotifyUser=0 and c.UserUIExperience=0 then 'Suppress all User notifications'
end as 'NotifyUser',
Case when (1 & c.OfferFlags) = 1 then 1 else 0 end as 'PreDeploy' --'Pre-Deploy Software to the User Primary Device',
Case when (4 & c.OfferFlags) = 4 then 1 else 0 end as 'CloseDefinedRunningExes' --Automatically close any running executables you specified on the install behavior tab of the deployment type properties,
Case when (8 & c.OfferFlags) = 8 then 1 else 0 end as 'AllowRepair' --Allow End users to Attempt to repair the application,
Case when (32 & c.OfferFlags) = 32 then 1 else 0 end as 'UseDialogNotToast' --When software changes are required, show a dialog window to the user instead of a toast notification

from

v_CIAssignment c where c.AssignmentType=2

 

;WITH
PCT9 AS (
  SELECT
  RawTypeID,
  TypeInstanceID,
  SkipUntil,
  ParameterValues.value('(/Parameters/Parameter[@index=3])[1]','integer') AS PCT
FROM
  v_Alert
WHERE
RawTypeID = 9
),

PCT10 AS (
  SELECT
  RawTypeID,
  TypeInstanceID,
  SkipUntil,
  ParameterValues.value('(/Parameters/Parameter[@index=3])[1]','integer') AS PCT
FROM
  v_Alert
WHERE
RawTypeID = 10
)

 

select Distinct
t1.AssignmentID,t1.AssignmentEnabled,t1.CollectionName,t1.CollectionID,t1.InstallOrUninstall,
t1.AssignmentName,t1.OptionalOrRequired,t1.WOLEnabled as 'Send Wake-up Packets',
t1.DPLocality as 'Allow clients on a metered connection to Download content after deadline',
t1.StartTime as 'DeploymentAvailableTime',t1.EnforcementDeadline,t1.TimeType,
t1.SoftDeadline as 'Delay enforcement per user preferences, up to the grace period',
t1.OverrideServiceWindows as 'Override Maintenance Window, for Installation',
t1.RebootOutsideOfServiceWindows as 'Override Maintenance Window, for System Restart',
t1.WriteFilter as 'write-filter handling, Commit Changes at deadline for Windows Embedded devices',
t1.RandomizationEnabled,t1.RandomizationMinutes,t1.UseBranchCache,
t1.EnableMomAlerts,t1.RaiseMomAlertsOnFailure,t1.NotifyUser,
t1.PreDeploy as 'Pre-Deploy Software to the User Primary Device',
t1.CloseDefinedRunningExes as 'Automatically close any running executables you specified on the install behavior tab of the deployment type properties',
t1.AllowRepair as 'Allow End users to Attempt to repair the application',
t1.UseDialogNotToast as 'When software changes are required, show a dialog window to the user instead of a toast notification',
COALESCE(PCT9.SkipUntil,PCT10.SkipUntil) AS 'CM Alert if Success SkipUntil Date',
PCT9.PCT AS 'CM Alert if Success Rate Percentage Less than this after the SkipUntil Date',
PCT10.PCT AS 'CM Alert if Failure Rate Higher than this percentage'
from #TempDeplInfoBase t1
LEFT JOIN PCT9 ON t1.Assignment_UniqueID = PCT9.TypeInstanceID
LEFT JOIN PCT10 ON t1.Assignment_UniqueID = PCT10.TypeInstanceID

--###############################################
--Cleanup any accidentally left behind Temp Tables
--###############################################

If(OBJECT_ID('tempdb..#TempDeplInfoBase') Is Not Null)
Begin
  Drop Table #TempDeplInfoBase
End

 

CMCB, SQL

  • Created on .

Windows 10 Inplace Update History Inventory

We were tasked at our company to get some statistics around machines which went through inplace upgrades, vs. machines which were on an 'original image' (or bare metal image, or whatever phrase you would like to give that).

With the assistance of --> Gary Blok <-- he suggested using the subkeys in the registry under 'HKLM:\System\Setup', which start with "Source OS ..."  Of course the problem was each and every computer which would go through an upgrade, would have a different key name.  That meant that in order to inventory that information, it would need to be a script.

Sample output; for example...what does it look like to see 'history' of machines which have gone through an upgrade? (and reported back the info from this script + mof edit)




select s1.netbios_name0 as 'ComputerName',
so.CurrentBuild0 as 'CurrentBuild'
,so.EditionID0 as 'EditionID'
,so.InstallDate0 as 'InstallDate'
,so.LatestOS0 as 'LatestOS'
,so.PathName0 as 'PathName'
,so.ReleaseID0 as 'ReleaseID'
,so.UBR0 as 'UBR'
from v_GS_SourceOS0 so
join v_r_system s1 on s1.resourceid=so.resourceid
Where so.resourceid in (
       select so.ResourceID
       from v_GS_SourceOS0 so
       Group by so.resourceid
       HAVING count(so.resourceid) > 1
       )
order by s1.netbios_name0, so.LatestOS0 desc, so.InstallDate0 desc

Sample output; for example...if someone were to ask you... Despite machines going to several upgrades, when was the machine originally imaged with a base image?



select s1.netbios_name0 as 'ComputerName', Min(InstallDate0) as 'Install Date'
from v_GS_SourceOS0 so
join v_r_system s1 on s1.resourceid=so.resourceid
Where s1.netbios_name0 = 'Computer1'
group by s1.netbios_name0


Attached --> Here <-- is a .zip file, containing three things.
- a .cab file if you just want to import the Configuration Item into your SCCM console
- 'SourceOS-IntoWMI.RenametoPS1.txt', the powershell script which is inside that CI.  Sometimes for some unknown reason, people are unable to import a .cab file into their environment.  You could create a new CI in your environment, using that .ps1 information, and the "what means compliant" would simply be existential, that any value is returned at all.
- 'SourceOS.mof' (for inventory import)

If you think this might be interesting to implement in your environment; here's the steps.

1) Either import the .cab file into your Configuration Items in your CM console
2) If importing of the .cab doesn't work, instead create a new Configuration Item, call it whatever you like, and the Setting will be a script type, string.  Paste in the contents of the 'RenametoPS1...' file.  the CI "test for compliance' will be Existential, that any value is returned at all.  
3) Add that CI to a Baseline of your choosing, and deploy the baseline to the machines you want to report on this information.  Perhaps it's only your Windows 10 devices.  I'd suggest having the baseline re-run 'every 7 days'--it really doesn't need to be more frequently, unless you have a lot of people hovering over your shoulder needing this info 'yesterday, and then every day forever'.  Frequency is up to you, but certainly not more frequently than daily.  More frequently than daily for this is overkill.
4) In your Console, Administration, Client Settings, Default Client Settings, right-click properties, Hardware Inventory, import the "SourceOS.mof".  Monitor your server's dataldr.log to confirm all is well.
5)  Wait.  Wait some more.  Wait a bit longer than that, up to a week.  <grin>  what you're waiting for is

a) the clients who got the baseline to run the baseline, and locally populate the completely-custom-wmi class of root\cimv2\cm_SourceOS. 

b) Then you're waiting for machines which have done that, to submit hardware inventory with that new, custom information.  Depending upon your environment, this could be hours... to days/over a week.  It all depends upon your environment, there is no one size fits all answer for how long you need to wait for most targets to report this information. 

c) After you've waited a bit, try out one or both of the sql queries above, to see if you have information.

Notes: in the 'SourceOS.mof'; I only set some of the values to TRUE for reporting.  If you think some of the other values which could be reported would be interesting for you to have, simply enable them in your console, so the clients start reporting those additional values.

CMCB, ConfigMgr

  • Created on .

ConfigMgr MaxExecutionTime Guesses for Updates

There is a situation which MIGHT happen for you.  The default for Cumulative Updates is, I believe 60 minutes now.  But many updates are still defaulting to 10 minutes.  I don't personally think that default should change, however, occasionally there are large updates (think Microsoft Office updates) which might be several hundred GB in size, and might take more than 10 minutes to install.  In your reporting, and when looking at local logs, the CM client says the install "Failed", but all you do is a re-scan for updates, and CM says it's installed.  So what gives, you wonder?  Well, this could be a possible reason.  It's not that the install 'failed' per se.  But after 10 minutes, the CM client stopped 'watching for' the successful install.  It timed out kind of.  Since I noticed a pattern that "it's usually when those updates are ginormous, they take longer to install", below is a POSSIBLE sql query to perhaps help you find and adjust the "Max Execution Timeout" on any individual updates.

A couple of pre-requisites.  Naturally, the content has to be downloaded. So if you run this 5 minutes after a "hotfix Tuesday" sync, it might not have much to say.  Because the content hasn't been downloaded to calculate "how big" any particular update is.  So you do have to wait until your content is downloaded to track these down.

Also note that I haven't created any kind of "powershell script" to automatically adjust the Max Execution Timeout.  This is just a report, and the admin would either posh-script changing each individual update, or use the console, find each update, right-click on it and in properties for that update, adjust up the max Execution Timeout to fit.

Also note these "suggestions" are just that, suggestions.  There is no right or wrong answer for how long Max Execution Timeout should be.  Leaving it all alone as-is with no changes from what you have will still work just fine.  One of the problems you may encounter might discourage you from touching or doing anything with this at all could be this following scenario...  Here's the scenario where following these suggestions would be a big bad horrible idea.  Let's say you allow your devices to have a service window every night for 4 hours.  Then you follow these suggestions, and for whatever reason, there were 8 different Office updates, and you changed them all from 10 minutes to 60 minutes each... for a total of 8 hours estimated time to install.  A client, when it gets the Software Update deployment, when it used to think "ok, these 8 will take me 80 minutes, I can do that in my 4 hour window, let's start!".  It'll start installing, and maybe it only gets 3 done... but it does get 3 done.  If you set them to 60 minutes each, the client might decide "wow, 8 hours... I can't do that in my service window... I'll just wait until I have 8+ hours to get this done".  and of course... it may never install any of them.  So be careful in deciding whether or not this is a potentially BAD idea, for your environment.  Or at least be aware of the potential repercussions, so you know what to un-do.

What this sql does, is list for Updates released in the last 30 days, and content has been downloaded, kind of look at the maxexecutiontime set, vs. how big the content is.  and if, for example, the content size is between 50 and 100mb, but it's maxexecutiontime isn't 20 minutes or more, then maybe you the admin might want to think about making MaxExecutionTime on that specific update to be 20 minutes--so you don't get false "I failed to install" reports which a re-scan will address.

Again... this isn't perfect.  It's just a possible suggestion, if you maybe have seen this behavior in your Software Updates deployments, and were wondering if there was a way to be pro-active about increasing the MaxExecutionTime without waiting for your reports to tell you the next day.

DECLARE @StartDate datetime = DateADD(Day, -30, GETDATE())
DECLARE @EndDate datetime = GetDate()

;with cte as (select ui.MaxExecutionTime/60 [Max ExecutionTime in Minutes], ui.articleid, ui.title, ui.DateLastModified, ui.DatePosted
,ui.IsSuperseded, ui.IsExpired
,(SUM(files.FileSize)/1024)/1 as [Size in KB]
,(SUM(files.FileSize)/1024/1024)/1 as [Size in MB]
from v_updateinfo ui
join v_UpdateContents content on content.CI_ID=ui.CI_ID
join vCI_ContentFiles files on files.Content_ID=content.Content_ID
where severity is not null
and content.ContentProvisioned = 1
and ui.dateposted between @StartDate and @EndDate
and ui.IsExpired = 0
group by ui.MaxExecutionTime, ui.articleid, ui.title, ui.DateLastModified, ui.dateposted, ui.IsSuperseded, ui.IsExpired
)

select
Case when cte.[Size in MB] < 50 and cte.[Max ExecutionTime in Minutes] >= 10 then 0
when cte.[Size in MB] BETWEEN 50 and 100 and cte.[Max ExecutionTime in Minutes] >= 20 then 0
when cte.[Size in MB] between 100 and 150 and cte.[Max ExecutionTime in Minutes] >= 30 then 0
when cte.[Size in MB] between 150 and 200 and cte.[Max ExecutionTime in Minutes] >= 40 then 0
when cte.[Size in MB] between 200 and 250 and cte.[Max ExecutionTime in Minutes] >= 50 then 0
when cte.[Size in MB] between 250 and 300 and cte.[Max ExecutionTime in Minutes] >= 60 then 0
when cte.[Size in MB] > 300 and cte.[Max ExecutionTime in Minutes] >=90 then 0
else 1
End as [Could use MaxExecutionTime Adjustment],
case when cte.[Size in MB] < 50 then '10 minutes'
when cte.[Size in MB] BETWEEN 50 and 100 then '20 minutes'
when cte.[Size in MB] between 100 and 150 then '30 minutes'
when cte.[Size in MB] between 150 and 200 then '40 minutes'
when cte.[Size in MB] between 200 and 250 then '50 minutes'
when cte.[Size in MB] between 250 and 300 then '60 minutes'
when cte.[Size in MB] > 300 then '90 minutes'
end as 'time to set'
, cte.*

from cte
order by [Could use MaxExecutionTime Adjustment] desc, [Time to set] desc

CMCB, SQL

  • Created on .
Copyright © 2021 - The Twin Cities Systems Management User Group