Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I work for a company that deliver distributed control systems for various industries. We find that IT Admin skills vary to a great degree both in terms of skills and interest. We have everything from a team of professional IT Admins on a Oil Production Plant to a part-time effort from the ships' cook.

The common Operator Station is on the windows platform and is usually delivered with recovery CD's with ghost images. This works, but is not very hightech and is less ideal for complex plants with lots of dynamic information and project stages with a lot of software updates.

We are looking into Virtual Machines and centralized site management for remote installation, Configuration revision (site info, tuning parameters etc), control software revision (binaries), System surveillance (error logs, alarms), Test Lab Administration, user administration etc, remote diagnostics/troubleshooting.

What would you as an admin like to see if you were to take a job at a giant production plant to manage the production network? What technologies should we be looking into for the system admins to benefit? Layman and IT geek alike.

What should be underlying logistics infrastructure and what would be good frontends?

share|improve this question
up vote 7 down vote accepted

My number one would be "Integration and testing with industry standard tools", the fewer bespoke update/deployment/monitoring/maintance interfaces I need to use on a daily basis the better.

Deployment - use Microsoft technologies such as Windows Installer Install Databases (MSI Files) to install, Windows Installer Patches (MSPs) and Windows Installer Transforms (MSTs) to provide custom configuration options. These technologies alone will allow software to be deployed with Active Directory/Group Policy alone, and in larger scenarios SCCM.

Monitoring - you couldn't go far wrong by publishing SNMP Traps or WMI Counters to allow third party monitoring software to see any errors or performance indicators that your application outputs.

Authentication - as mentioned by mh, Integrated authentication is a huge advantage for those in a Domain environment, it isn't suitable for a small workgroup so that needs to be considered.

Configuration - my personal preference is text based configuration and user files (Cache, etc.) in %APPDATA%, text files can be manupulated or deployed by scripts and I can elect to not propagate changes to the file system back to the server. mh brings up a valid point about using the registry for group policy, the majority of cases the Registry is the best place for configuration; don't put too much in there however it is designed for a few KB of data per application not, megabytes.

share|improve this answer
+500 (if I could) for mentioning Windows Installer. – Evan Anderson Jun 23 '09 at 11:48
Likewise; standard tools designed to work for these kinds of deployment are there for a reason - to remove pain from the deployment process - so they should be used. – Le Comte du Merde-fou Jun 23 '09 at 12:00

For security it has to be integrated authentication all the way. It may be fun to develop your own authentication mechanism, or to use a third-party method that you believe is more secure or flexible than integrated, but it means more usernames and passwords to be managed, your admins won't like you for it, and nor will your users.

For configuration, stick to the registry. Seriously. The great registry vs config files argument is fine for standalone machines where the user doesn't mind modifying config themselves, but for real end users with remote systems there is no argument. Use of the registry means that initial config and any changes can be easily deployed using Group Policy, or - for cases where Group Policy is not available - by just double-clicking a .reg file. Changes can be incrementally merged, and - by using HKCU - it works properly in a multiuser environment.

The initial config is very important. Avoid dialogs such as "now enter the name of your jarglepoink server" during this phase. Initial config should work without any need for user interaction or input. Look at how a GPO-managed MS Office installation works - properly set up, a user never has to enter either their user name or Exchange server name during Outlook first run. Copy that.

For data access, use a DSN-less connect string. ODBC config is not too hard to push to remote users, but it's another layer of things to go wrong; going DSN-less helps to remove complexity at that side.

Test test test. Test as a standard non-Admin user. Ensure it works. Log out and log back in as a different standard non-admin user. Ensure it still works. Ensure that settings which are common stay common, and that settings which are not common stay not common.

All of this - and the recommendation above re: MSI - should help to create a setup where a user's PC never has to be either physically visited or remoted into in order to carry out work relating to the app.

share|improve this answer
+1 for mentioning group policy-based management. "jarglepoink" is really, really nice, too. – Evan Anderson Jun 23 '09 at 11:49
For authentication, I would personally say give me the option. Integrated authentication is great for domain environments, it isn't always practicable in a multi-user workgroup environment. – Richard Slater Jun 23 '09 at 11:53
Fair point, no argument here. :) – Le Comte du Merde-fou Jun 23 '09 at 16:20

The thing I'm missing most is proper documentation.

A high level view would be something like:

  • all switches properly documented
  • when does the app need a restart
  • how is logging configured
  • etc, yadda yadda (actually that depends on the need of the customer)
share|improve this answer

Use or develop apps that get you out of the software deployment business. I'd want apps that phone home each time they start to check for updates, and then can update themselves, or SaaS type apps where 95% of the app is server-side.

Anything you can do to avoid end-user phone calls and emails is worth the money and time you spend on it.

share|improve this answer
Auto-update is the bane of my existance, the majority of them don't expect to be run in a least privalage environment, let alone one where the desktops are heavily locked down such as school, college or university. It seems that many manufacturers decide that once they have a bespoke update service they don't need any other way of installing or updating software, leaving my bedragled technicians to visit 700 computers to log on as an administrator just to update software. – Richard Slater Jun 23 '09 at 15:22
In that scenario, I would definitely agree with you about auto-update. In fact, I would say you're in hell no matter what, unless you are willing to invest a small fortune in tools and/or people. I lived your life once or twice already. 3600 remote PCs in three states spread across 300 locations. I understand the problem space quite well. As long as apps are distributed, there is no silver bullet. Re-centralization, or technologies that "fake it" (e..g auto-update) are the light at end of the tunnel. They just need to evolve a bit more. – Scott Kantner Jun 24 '09 at 15:50

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.