Desktop Error Monitoring

This was an excellent session which covered a component of the MDOP suite called Desktop Error Monitoring (DEM). I was extremely impressed with this product demonstration and can see immediate use for it in both our current and future environments. The tool would assist primarily the tier 3 teams (EUT), in strategic problem solving, but would also be useful to tier 2 teams in terms of published problem management, and statistical information. I understand that the tool itself is free, however because we don't have desktop OS enterprise licensing, there will be some commercial issues which would need to be ironed out prior to us deploying - I certainly intend to pursue this investigation, and if necessary raise a business case to implement MDOP as the benefits are clear and immediate.

In order to describe the product, the speakers first talked about why the product exists - this was mainly user need driven:

• Provide an immediate ROI
• Deliver end to end solutions
• Better TCO on desktops/laptops
• Requirement for low cost monitoring for knowledge and productivity issues
• Requirement for better visibility of desktop issues (users automatically reboot, often overwriting error data in the process)

DEM offers the following to help with the above:

• Crash monitoring
• Application and System crash/hang data captured and stored centrally
• Direct access to troubleshooting & solutions
• Agentless deployment (via group policy)
• Lower helpdesk volume calls
• Engagement with support partners
• Internal 'Watson' back-end
• Patch and update tracking
• Easy analysis of captured data reports

The requirements for a DEM deployment are pretty standard:

• A management server
• A reporting server
• An SQL server
• Active Directory
• Global Policies in use in the environment

It's worth noting that DEM is a separate product to SCCM, although SCCM does effectively do the same job albeit on a much bigger scale. DEM is focussed directly on the desktop/laptop environment.

DEM also offered such features as customisable web pages displayed on the desktop when a crash occurs - which means that if we have a solution or workaround already, the user is notified straightaway. This has an obvious effect of reducing helpdesk calls. DEM can also suppress the "Send details to Microsoft" dialog, which users as often as not will click "No" on - once deployed, DEM automatically sends the error data to the central server, and then can display the kind of web page as described above.

Along with application issues, DEM also records system errors such as the dreaded BSOD. One of the issues EUT has faced recently is the issue of collecting BSOD error data - our environment is such that this is not easy on all devices and the user was usually forced to reboot prior to the full error log completing - this could be negated with the DEM system. It is often essential for our vendors that we provide complete error logging so that they can quickly resolve these types of issues, so anything that can help with this will be invaluable to us.

In addition to error data, DEM also captures the CAB file associated with application issues and bundles this in with the reporting - this would help Satyam with issues in packaging and us with patching and update problems. When use in conjunction with crash analysis tools, this is a very powerful way of identifying issues in applications.

In terms of UI, DEM looks very much like SCCM. It has facilities groups similar issues together, but in granular detail (ie by revision/version of individual DLLs) so things like video driver errors etc are clearly visible, even on a cursory glance at the logs.


As I said in the beginning of this article, I intend to follow this up with a serious intent to raising a business case to implement this technology in our environment as soon as possible. It can be used very soon - as soon as the new AD is in production to be exact, and I think the support teams will see the practical benefits immediately. Management should also see benefits from this too - apart from the obvious potential to improve our problem management, quicker and more proactive issue resolution and the potential for ticket reduction; they will also enjoy both the high level reporting available, with the options to produce highly granular reporting if required as well.

Best practices from Microsoft IT on Config Manager 2007

This was a nice wrap up to the day - the internal MS IT department team lead gave a presentation on how they handle the normal everyday jobs that all users of their products need to do.

The thing that surprised me was that they do not seem to be early adopters of their own technology...obviously they are heavily involved in the Alpha, Beta and QA for their new products (a process they delightfully call "Dogfooding", but in their own environment, they have only recently implemented some of the things I just assumed they would use from day one of it going gold. To give you a couple of highlighted examples, they only began to deploy O/S images six months ago using MDT, and only use one App-V based application throughout the entire organisation.

The other surprise was the size of their team - although the speaker did admit they outsourced for some tasks, their core team is only 13 people. This team services 274,000 clients based at six HQ and client sites globally.

Their SLAs are quite impressive too - for software compliancy (patching etc) they adhere to a 95% compliancy within 3 business days for active exploit patching. For critical updating the SLA is 95% within nine business days.

A large portion of the presentation was around performance monitoring - with such a large organisation which such a high data throughput, they needed to develop their own type of custom reporting, which they achieved with the LogMan tool, and a bundle of custom scripting.

One last point which was quite interesting - they stated that their DC operational costs had reduced by 75% using a virtualisation strategy - they have defined an 8-1 virtual to physical server ratio. They claim that most of the 75% savings are down to power and physical server cost savings, along with standardising the builds for easy and fast provisioning.

Software updates for smart admins

"Software updates for smart admins" consisted of two admins, one from a 50k user strong company, the other with barely 2k users. The point was to show best practices on software updating from different perspectives, with often diverse methods, but ultimately achieving the same end result of software compliance. The session was lively and obviously both admins had very different views on achieving their goal, and although they didn't quite argue about it on stage, they did agree to disagree. The only things they did agree on was that WSUS was old and SCCM was infinitely easier to manage. That and don't sync drivers, which seemed pretty obvious....who wants to download 70gb+ a month?

I will be getting the slide deck from this one though, as some of the methods described looked like they could save quite a bit of time for any admin - please let me know if you'd like a copy.

How do they do that?

An interesting session for a couple of reasons. First, hearing about how exisiting customers are working around product limitations is a great way to find out the 'real' product limitations. Second, there was a discussion about 'best practice' application packaging and deployment which is as relevant to our current environment as it is to Microsoft System Center customers.

The slides are pretty good so I won't go into too much detail here, but some things we should think about are Desired Configuration Management (DCM) and a consistent hardware decommissioning process. Our process and organisation actually map fairly well to best practice with the noticeable exception of our insistence on 'bundling' the applications into monolithic updates, but it seems to me this stems from a lack of automation at the site end, so we should carefully consider what can be done to reduce the burden on our local infrastructure teams.