The first time I ever broached the subject of network downtime with an employer, he was horrified: "What do you mean? I thought this was supposed to run 24 hours a day, everyday!" It took me longer than it should have to calm him down and explain that it was quite normal for the system to occasionally close down. I compared it to the regular servicing required by his car or central heating boiler. In retrospect, I realised, it would have been wise to have mentioned this subject before it became a necessity. Whether it's for regularly scheduled maintenance or to deal with an unexpected snafu, the network has to be down at some point. The important thing is to make sure that company employees are aware of the possibility of downtime and that, in fact, they should occasionally expect it. Here are my suggestions on managing users' and executive managers' expectations for both regularly scheduled and unplanned downtime. Regularly scheduled downtime
If it proves necessary to close the system for maintenance, you'll want to discuss the timing of the shutdown with all departmental heads to try to reach some form of agreement. You usually won't be able to please everybody, but you'll want to be sure that the impact is contained as much as possible. It might be necessary to perform maintenance after normal working hours. For example, if your office runs 9am to 5pm, it may be best to schedule downtime for the early evening. That way, you can fix any problems and get things up and running again before the morning. If your offices operate 24/7, there will never be a good time to perform maintenance, so talk to your users and negotiate a time. When you have decided on your maintenance time period, make sure you have everything planned meticulously so that the whole operation is as smooth as possible, and you are up and running again before your scheduled time slot has expired. It can be costly and humiliating to shut the network down for some routine work only to find that, at the end of it, you are unable to restore the service because you forgot something. Therefore, your preparations should involve a test rollout of the planned upgrade. Use this test to assess the impact the upgrade will have and to ensure that it has no unforeseen side effects. It's also important to document the effects of your test rollout. I have found it very useful to keep a server diary in which I note everything that has altered on the system. Send multiple notifications
You'll want everyone to have notice of the event well in advance, so send out email reminders one week before the event and again one day before the event. Then, a few minutes before the shutdown, send a system message to all logged-on users to make them aware that they have five minutes to save their work and log off. Keep a log of all messages that you send out -- inevitably, someone will always say they weren't told.