Paul's TechSexy 1: great client deployment monitoring, thanks to v_ClientDeploymentState
Summary: client deployments (new installs or upgrades) are a critical part of the life of any SMS administrator. Whether you're rolling out your first infrastructure or upgrading a well established one, you can't really take advantage of SMS until you've done most of the client deployments. But how do you verify the client deployments are going well?
Traditionally you did the monitoring according to the method you used. If you did upgrades via software distribution, then you watched software distribution status messages. If you used push installation, then you watched the push logs and file counts. If you did it via logon script or computer startup script, then you rolled your own solution. In all cases you watched the system resource activity (DDRs, as seen in v_R_System). So you had options, but they only told you part of the story, and you couldn't use one solution for all methods.
Now with SCCM 2007 we have a great solution in the form of the Fallback Status Point, whose data rolls up very neatly to the v_ClientDeploymentState view at your central site. What makes it so great? Well, it's universal - all client deployment methods can use it. More importantly, it's more granular - you can see who tried what and who succeeded, at both the client installation and site assigment stages. If reboots are needed, you can track that too. Failure messages are very detailed.
From SMS 2003 you may be used to views like v_ClientAdvertisementStatus or v_GS_PatchStatusEx. They were brilliant in that they gave you the latest status for advertisments or patch deployments. If you only had a few thousand clients or less you could always do that via the original SMS views, but if you had more clients then those original views were prohibitively slow. v_ClientAdvertisementStatus and v_PatchStatusEx accumulated the results as they rolled in, and so when you ran your reports they told you exactly what you needed right away, even if you had a couple hundred thousand clients.
v_ClientDeploymentState now does the same thing as v_ClientAdvertisementStatus and v_PatchStatusEx. Complete, fast, fully detailed client deployment status: brilliant. TechSexy!
Ok, enough background - how are you going to use it? Well, there are some built-in SCCM reports that may do the job for you. But chances are you're going to want to dive deeper, sooner or later. So:
To start with, you'll want to watch the key deployment phases. The following queries do that, including percentages. Each phase has the potential to fail, so they won't likely all give "100.0%" as the result, and likely each phase will be a little less successful than the previous one:
declare @total as integer
select @total=count(*) from v_ClientDeploymentState where LastMessageStateID is not null and SMSID is not null
select @total 'clients'
select count(*) 'deployment started', count(*)*100.0/@total '%' from v_ClientDeploymentState where DeploymentBeginTime is not null
and LastMessageStateID is not null and SMSID is not null
select count(*) 'deployment done', count(*)*100.0/@total '%' from v_ClientDeploymentState where DeploymentEndTime is not null
and LastMessageStateID is not null and SMSID is not null
select count(*) 'assignment started', count(*)*100.0/@total '%' from v_ClientDeploymentState where AssignmentBeginTime is not null
and LastMessageStateID is not null and SMSID is not null
select count(*) 'assignment done', count(*)*100.0/@total '%' from v_ClientDeploymentState where AssignmentEndTime is not null
and LastMessageStateID is not null and SMSID is not null
Extending those queries a bit will give you the count of computers that fail in each stage, for example in the deployment stage:
select count(*) 'deployment failed', count(*)*100/@total '%' from v_ClientDeploymentState where DeploymentBeginTime is not null and DeploymentEndTime is null
Better yet, you can get the details on why they failed:
select StateDescription, LastMessageStateID, LastMessageParam, count(*) 'clients' from v_ClientDeploymentState where DeploymentBeginTime is not null and DeploymentEndTime is null group by StateDescription, LastMessageStateID, LastMessageParam order by 4 desc
Or get the computer names so you can investigate them to confirm the exact details:
select NetBiosName from v_ClientDeploymentState where DeploymentBeginTime is not null and DeploymentEndTime is null
If you poke around at the view you'll see that there are success states as well as failure states, so you might think you could do your success reports based on the relevant sucess state messages. However, there are some exception state message IDs, like 401 and 402, that schew those results. So you're better off to look at the relevant stage columns (deployment start, for example), rather than the state messages IDs, when you're looking at anything other than failures.
Another interesting avenue of investigation is the length of time that the successful deployments take. Most are fast, but the slow ones are worth investigating:
select DeploymentBeginTime 'beginTime', DeploymentEndTime 'endTime', datediff(second,DeploymentBeginTime, DeploymentEndTime) 'duration' into #temp1 from v_ClientDeploymentState
declare @withduration as integer
select @withduration=count(*) from #temp1 where duration is not null
select min(duration) 'fastest (seconds)' from #temp1
select max(duration)/3600 'slowest(hours)' from #temp1
select count(*) 'more than an hour', count(*)*100/@withduration '%' from #temp1 where duration>3600
select count(*) 'more than 3 hours', count(*)*100/@withduration '%' from #temp1 where duration>3600*3
select count(*) 'more than 12 hours', count(*)*100/@withduration '%' from #temp1 where duration>3600*12
How many clients need reboots to complete the client installation (and why?) (note that the 401 and 402 messages track the reboot needed/happened status:
select StateDescription, LastMessageParam, count(*) from v_ClientDeploymentState where RebootNeeded='*' group by StateDescription, LastMessageParam order by 3 desc
Which sites are the clients being assigned to?:
select AssignedSiteCode, count(*) from v_ClientDeploymentState where AssignedSiteCode is not null and AssignedSiteCode<>'' group by AssignedSiteCode order by 2 desc
I'm sure you're seeing the possibilities this view makes possible.
p.s.: "TechSexy" probably means different things to different people, but to me TechSexy stuff is SCCM changes that make my life better, in any substantial sense. I can show them to anyone that knows SMS and they'll know that they're 'cool'. Not necessarily cool in the sense of Zune or Xbox 360, but cool in that they make computer management more 'vital and alive'. Responsive to my real needs. My life is better in a big way.
SCCM has plenty of new features that the marketing guys will tell you about that make SCCM 2007 more valuable to you than SMS 2003. I'm excited about those features, will use them extensively, and they help the Microsoft IT team to deliver value to Microsoft well beyond the costs of running our infrastructure and the team. But "features" are one thing and "TechSexy" is another. Oh, and they can't be in SMS 2003, because then they wouldn't be what makes SCCM uniquely TechSexy. So when I share TechSexy ideas, they are fun SCCM ideas you might not find anywhere else, baby!
(Then again, defining cool is not cool. So I won't do it again)