Bladewatch.com

I was interviewing Mike about best practice in the Windows design field for an article I am researching. Windows design means taking the Windows operating system and creating an image, a corporate build standard that can then be deployed to servers throughout the enterprise in order to have a standard platform for business. The concept being that if I build a server in New York, it should be the same as a server build in New Hampshire. By having a unified build, the design team can establish the core requirements, mandate security baselines, drivers and layered components in order to meet IT Security standards and policies.

Mike however has an interesting organizational challenge which we were talking about.

“We have to support whatever servers are in the support matrix”

“That means our build, has to be able to support everything from a DL360 G3 (we have just changed what is supported) up to the latest and finest servers that are being bought by the HPC team or the business unit deploying new web infrastructure or Citrix servers.”

The challenge being that what is acceptable in a small remote site supporting fifteen users, might not be in a large deployment, similarly what is suitable or standard in a large site, might not be possible or supported in remote small offices, where a DL360G1 is in effect all they need.

Mike’s challenge?

As the range of servers expands, the build is designed from an infrastructure lowest total cost of ownership angle – it therefore does not necessarily keep up with the latest and greatest versions of .NET and we have to validate configurations, and drivers retrospectively and going forward, the drivers we load have to be compatible with the DL360 G3 and the ML370s, we need to be all things to all people. This causes an issue, as the range of servers supported grows so does the amount of time spent on validating the server build against the different platforms.

There is a drive to virtualize legacy servers from the production guys in our London head office, they deem anything that’s older than three years as legacy, that’s not necessarily the same for our sites supporting say 30 users in an Exchange and DC scenario. As production in London reduce the number of legacy servers in an effort to reduce costs including their hardware support contract, where does this leave us in terms of support both in testing and validating for specific platforms.

What else is an issue?

Hardware failures – operationally in that it can take longer to get parts for an out of support system

Maintenance debate – whether we should continue paying to support an obsolete system

Marginal design cost – am I validating the build against a platform that might be only used in 8 of their 100 offices?

Being able to easily drop support for a platform – how many sites/customers will that impact and who defines what is in and out of support or operationally a production risk?

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.