Globalize Networks blog

At a large HMO I used to work for, they used to have a tough re-image policy.  I believe that if a problem took more than two hours to solve, they would just have the desktop support person re-image the machine.  This approach did lead to plenty of problems, lost user data, etc.  But, if managed properly it probably could have cut down on user downtime and support costs.

1. User data – My current approach is to backup all user data to the server anyway.  Sometime users will save files outside the standard folders (i.e. My Documents).  This HMO also had a clever script that would locate all supported data files (i.e. – .doc, .pdf, .pst, etc.) and back them up prior to the image drop.
2. Non-standard software – Once drawback to this method is that IT didn’t necessary have images that included ALL of the software required by all the departments.  One group required SAS tools that weren’t in the base image.
3. Software updates – This approach would work best if the images were updated with the latest Windows updates, etc.   Otherwise you need to re-run all the patches each time you drop an image.
4. User profiles – On the one hand you could keep the user profile on the network, but on the other hand sometimes a corrupt user profile is the cause of the problem.

I haven’t tried this method at the small business level, but I think that it would be very difficult to reduce support costs by taking this approach.

I had a lively exchange with another consultant today that included a discussion of imaging client machines. This other fellow subscribed to what I think is an old school philosophy that there should be a separate volume for the system and the data on client machines. I still subscribe to this view in regard to servers – but in that case we are usually talking about different disk arrays (i.e. a two-drive RAID 1 container and a N-Drive RAID 5 or RAID 10 container)

So his primary argument in favor of a separate system volume (or partition in his case as he is an adherent to FAT32 – which is a whole other can of worms) was that he can keep a “ghost” image on the data partition and if there is ever a problem with the system partition or if the OS won’t boot, he can walk the end-user through booting to DOS and running a script to re-image machine. Now I like the creativity of this solution, but here are my reservations:

1. Using FAT32 is probably causing as many blue screens as it solves. Because it’s not a journaling file system, you are more likely to run into problems whenever Windows is ungracefully shut down.
2. Having users self image a machine risks overwriting data that might have been unknowingly saved to the system partition.
3. It can be a waste of disk space if you allocate too much space for the system partition, but you risk filling it up and bringing the system down if you allocate too little.

I think it’s simplest to just keep one partition.

1. You don’t need to worry about resizing partitions or wasting disk space.
2. Simplifies administration (no need to document or train admins on this aspect of a client build)
3. You can save a base “ghost” image to the fileserver or on a USB drive somewhere. If you do want to risk having the end-user re-image their machine, you can have them first backup their current image to USB.

Of course client data backups are a must:

http://globalizenetworks.com/blog/2008/05/22/client-backups

For corporate Video Conferencing, we usually have a dedicated “codec” from Tandberg or Polycom.  However, we recently ran across this offering from Sony which works well, has nice modular add-ons, supports the latest protocols, and is more economical:  Sony iPela PCS-G50
(CDW is a good corporate vendor if you want to simplify purchasing – not the best prices, but decent)

NetMeeting is a deprecated Microsoft H.323 client.  Looks like Microsoft wants to push everyone over to Live Meeting.  It’s still included in XP though (START | RUN | Conf), and I guess that you can install it into Vista: http://en.wikipedia.org/wiki/Microsoft_NetMeeting

We have been using NetMeeting to test H.323 connectivity and to link in remote users.  (Multi-site capabilities in the VC codec usually cost more.)

I have come to conclusion that it doesn’t make sense to keep your codec behind a firewall, I agree with this site: http://www.more.net/technical/video/troubleshooting/videofirewalls.html.  Basically just turn off the web-interface and other IP services and you should be secure.  I have many bumps on my head from H.323 firewall configuration.