Client Management Suite

 View Only

Software Rollout Speeds -Where's my Sonic Boom? 

May 23, 2017 11:29 AM

One question I am often asked is how fast "software x" can be pushed with Symantec's IT Management Suite (ITMS). This question is generally posed in terms of an urgent software rollout, a patch, or our agent updates which occur when we upgrade the SMP server.

We can answer this in a rather concrete way, and in what follows I'll explain how.

Sections in this article,

  1. The Effect of Green IT
  2. Getting to Know Your Client Connection Profile
  3. Repercussions Of Our Our Client Connection Profile
  4. Calculating Your Client Connection Profile (the T-SQL bit)
  5. Summary

 

The Effect Of Green IT

To answer the question of how fast we can do anything to our computer estate, we have to first explore the statistical impact of machines being powered off. I hope I'm preaching to the converted when I say that to deploy software to any given machine it must first and foremost be turned on. The biggest impediment to this however are "Green IT" implementations which omit a reliable method to wake up your estate.

In today's more environmentally aware world, it's common practive to have sensible power management profiles deployed across your managed estate. This makes a cool saving on the organisation's utility bills and correspondingly saves a bit of CO2. This helps reduce costs when staff leave the office at the end of their working day, as well as naturally taking into account the times when they don't return (like training, sick days, and holidays).

So, with envionmentally-conscious power management profiles, you are naturally going to increase the disconnected time of your computer estate. This will have a natural impact on how fast any given software deployment can percolate in the absense of a wake-up mechanism. In this article I'll show that the minutes (or even hours) that any chunk of software takes to install can be insignificant from a compliance viewpoint when computer on-time it taken into account.  

 

Getting To Know Your Client Connection Profile

When we started deploying software with ITMS, one thing were provided with was a visibility of deployment progress. This led initially to a bit of disappointment -our deployments were not progressing as fast as we'd hoped/guessed. 

Consequently, I decided to explore what I now call our "Client Connection Profile". This profiling gives us an indication of how likely it is for a client to report back to our SMP within any given time period.

What we found was interesting. To show you what I mean, let me show you a recent profile,

Res2.png

This looks a bit busy, but what does this tell us? Let me talk you through the results:

  • Day 1 -We had 68% of our estate connect to the SMP (this was a Friday)
  • Day 2/3 -We observed just a 2 point rise in unique machine connections (it was the weekend)
  • Day 4-6 -In these three days we see a further 15% of our clients report in
  • Day 7-8 -We observe a further gentle 4 point rise
  • Day 9-10-We flat line (it's the weekend again)

After running through a few of these, what I can in general say about our estate is that,

  1. On a typical working day, we can reasonably expect about 68% of our estate to report in
  2. Over weekends, we don't capture many new clients
  3. If we want to put a time window around having 90% of clients to connect, we're looking at two weeks
  4. We have about 5% of our estate which doesn't appear to be reporting to the server even after one month
    (I suspect this is due to our inefficient asset retirement process)

 

Repercussion of Our Client Connection Profile

When we now rollout any software, we now know how our estate's power management influences our client connection profile. This is invaluable. I can now say with a fair degree of certainty that,

  1. 75% compliance after three working days
  2. 90% complaince after 2 weeks
  3. 95% compliance after 1 month
  4. 100% compliance currently unachievable (as we can't force into compliance machines which we no longer see) 


It is important to note that in our case that this profile is not due to infrastructure scaling, or network issues. This is simply a direct repercussion of turning machines off without having in place a scaled approach to waking them up. This is obviously something for us to focus on if we want to increase our compliance statistics.

We anticipate that implementing WOL and/or vPro will certainly make a significant impact here. 

Calculating Your Client Connection Profile (The T-SQL Bit)

To grab your profile, paste the following chunk ot T-SQL into SQL Server Management Studio and execute it. On one of my backend servers, which serves an SMP with 3000 nodes, this takes about 5 seconds.

/*
Client Connection Profile, ian.atkin@it.ox.ac.uk
 Version 1.0
----------------------------------------------------------------------------------------------------
 Summary
----------------------------------------------------------------------------------------------------
   When upgrading Altiris Agents, it's useful to know in advance what you can expect in terms of
 the rollout speed across your estate. As agent upgrades can happen no faster than the rate that
 clients normally connect to your SMP, an intelligent estimate of the rollout speed can be found
 by examining how your agents normally connect to the server.
 
   This is not as simple as saying "Well, our agents are configured to update every two hours" as
 there are many reasons why machines will not contact the SMP. For example, staff training, holidays,
 computer sleep settings, and inefficient asset retirement processes.

   The SQL here will extract from the Evt_NS_Client_Config_Request a mapping of how your clients
 have connected over the last 30 days. The output a column of the number of distinct clients
 that have connected during the 30 day window. 
 
   In most scenarios, when you plot this the output will be bumpy with a periodocity of 7 days.
   This is to be expected in organsiations where computers are set to sleep (or are turned off)
   over the weekends.  
 
----------------------------------------------------------------------------------------------------
 Known Issues
----------------------------------------------------------------------------------------------------
  The Evt_NS_Client_Config_Request table is not infinite! So how far back in time you can search for client
  connection data will depend on how your environment is configured.
  
  In an environment of 3000 machines, with an hourly connection profile, you should get about a month
  (as Evt_NS_Client_Config_Request by default will hold 1 million rows) 

  i.e. If clients are connecting 100% of the time then we have,

  
  But, generally speaking, the average workplace will have power saving in place, so in reality
  the estate will only be turned on perhaps 30% of the time in any given week. Consequently, 
  in the 3000 client scenario with 1hr config updates set, we'll see this table hold 40 days
  or more of useful data.
  
----------------------------------------------------------------------------------------------------
 Method
----------------------------------------------------------------------------------------------------

This means having an algorithm that does the following,
  1. Set @DateToday = First thing this morning (i.e. midnight)
  2. Set @TargetDate = @DateToday -1 day
  3. Calculate All distinct Clients that Connected on between @TargetDate and @DateToday
  4. Move the target back a day (Set @Targetdate = TargetDate - 1 day)
  5. Calculate All distinct Clients that Connected on between @TargetDate and @DateToday
  ... and continue..

*/
IF OBJECT_ID('tempdb..#ClientProfile') IS NOT NULL
   DROP TABLE #ClientProfile
  
CREATE TABLE #ClientProfile(
Total int)

declare @DateToday datetime
declare @Targetdate datetime
declare @myMonth int
declare @myDay int

declare @i int
set @i=0

while (@i<30)
begin
  set @i=@i+1
  set @DateToday= DATEADD(d,0,datediff(d,0,getdate()))  --The moment today began
  set @TargetDate= DATEADD(d,-@i,datediff(d,0,getdate()))  --i nights ago
  set @myMonth=MONTH(@Targetdate)
  set @myDay=DAY(@Targetdate)

  insert into #ClientProfile (Total) 
  
  select Total from  
  (  select COUNT(*) as 'Total' from 
       (
       select distinct ResourceGuid
       from Evt_NS_Client_Config_Request 
       where _eventTime between @TargetDate and @DateToday 
       ) xxx 
  ) yyy

end

select * from #ClientProfile

 

The output of this can be pasted directly into EXCEL and made into a chart.

 

Summary

Understanding how your computer estate reports into your SMP is vital if you want to give realistic projections on software rollout speeds. This is important when predicting the pace of agent upgrades, software rollouts and patching.

I've shown in this article some simple T-SQL which helps reveal the client connection profile of your estate. This can help you understand in a quantitative way the impact of power management on your compliance in these areas.

In our case, I hope that metrics like these can help revitalise our old vPro project proposals that failed to get off the ground. The world is full of infinite possibilities after all.

 

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

Oct 17, 2017 08:53 PM

Thx

Jun 06, 2017 05:52 AM

Hi Tomasz,

Yes -indeed this is only part of the picture. What it does do is let you know the best you can achieve if you don't have a reliable WOL mechanism. In terms of reboots, you simply have to add x-days to these figures in line with whatever reboot notification windows you have in your software/patch rollouts.

Thanks for posting your results btw... it's good to see another environment displaying similar data.

Kind Regards,
Ian./

 

May 31, 2017 03:43 AM

Thanks Ian for the query.

That is pretty interesting article. I am nicely surprised by the picture in my environment and I ma a bit in doubt at the same time. On the other hand we make quite some effort to sort out the unmanaged clients.

Agent profile.png

Agent connectivity is only one part of the picture. Some software or updates need restarting to complete the installation, which can be challenging without forcing users to do so.

Related Entries and Links

No Related Resource entered.