How should applications be developed for easy deployment?

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?

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.

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.