WSUS and McAfee Protection Pilot

[Genessy]

I would like to upgrade from SUS to WSUS on a server that is also running
McAfee protection pilot. When I attempted to install the release candidate
of WSUS, it broke my McAfee installation. As far as I could tell, they were
fighting over the same database. Does anyone know if that has been fixed, or
what this database ignorant girl can do to keep it from happening again? I
would really like to upgrade to WSUS since it has a lot more management
options, the ability to update MS Office products as well, and if rumors were
true, I won't get the calls about the reboot dialog having a grayed out "No"
from terrified users.

[Genessy]

Additionally, can someone cofirm that last rumor? Do users actually get the
option of selecting "No" to the reboot when NoAutoRebootWithLoggedOnUsers is
set to 1?

[Lawrence Garvin]

That "rumor" is inaccurate, Genessy.

The "NoAutoRebootWithLoggedOnUsers" merely ensures that the logged on user
will be notified prior to the restart being initiated.

Whether the user gets the option to "Restart Later" is a function of their
access level -- not this setting. Local Administrator enabled accounts will
have the option to "Restart Later", but they'll also have the option to
control when/if the updates are even applied.

The purpose of the setting is merely to keep users from being subjected to
an unannounced restart in the event an update is installed while the user is
logged on.

Ideally updates will be scheduled to be installed when users are normally
logged off (i.e. overnight), but this is not always possible.

Post by Genessy
Additionally, can someone cofirm that last rumor? Do users actually get the
option of selecting "No" to the reboot when NoAutoRebootWithLoggedOnUsers is
set to 1?

[Lawrence Garvin]

I can't imagine how there could be a database conflict, as on Windows Server
2003 WSUS installs it's own private instance of WMSDE, which is a database
only available with a limited list of products.

On Windows Server 2000, it is necessary to manually install a named instance
of MSDE2000A, and WSUS shouldn't even be installing a database environment
in this scenario.

As a generic idea, I'd say try disabling (or uninstalling, if necessary) the
McAfee, install the WSUS, and then reinstall (or re-enable) the McAfee.

Once more.. the grayed out "Reboot Later" will be a normal indication to
non-admin users; however, those users will be presented with a dialog box
with a button to "Reboot Now". Until they click on that button, the system
will not restart. In the early days of testing WSUS, I was presented with
such a dialog box (not having read deep enough into the docs), and simply
moved the annoying bugger out of the way until I was ready to restart.

Post by Genessy
I would like to upgrade from SUS to WSUS on a server that is also running
McAfee protection pilot. When I attempted to install the release candidate
of WSUS, it broke my McAfee installation. As far as I could tell, they were
fighting over the same database. Does anyone know if that has been fixed, or
what this database ignorant girl can do to keep it from happening again?
I
would really like to upgrade to WSUS since it has a lot more management
options, the ability to update MS Office products as well, and if rumors were
true, I won't get the calls about the reboot dialog having a grayed out "No"
from terrified users.

[Genessy]

Thank you for your help. I had hopes for the reboot having more options
after reading SUS message boards that seemed to think that WSUS would correct
what I see as a problem. Our policy has always been to shut down at night,
or I would have no trouble setting the install and reboot for after hours.
So, unless I want to elevate non-admins, my users may just have to learn
something. I sent out an e-mail before I implemented SUS on the clients, but
my coworkers and I still got dozens of calls. I will give WSUS another
attempt and hope that I can avoid the same conflicts I encountered when
trying to use the release candidate. If I run into trouble again, I will try
your advice. Thanks again.

[Lawrence Garvin]

If you have a company policy for powering down every night - and many do...

Here's a methodology for handling that:

(1) For the machines running XP SP 2 -- enable the option to "Install
Updates at Shutdown", combined with notification of update approvals, so
that users anticipate the presence of that option when it appears. When the
policies affecting this option are set to "Disabled" (rather than Not
Configured, as documented incorrectly), the user will be presented with the
"Install Updates and Shutdown" option, by default, and the updates can be
installed at the end of the workday.

This entirely eliminates any issue with user intervention, Local Admin
privileges, or issues of restarting during the workday.

For Windows 2000 systems, this option isn't available, so you're limited to
the cooperation of the users, and a scheduled install time during working
hours. In this case, scheduling the install at 4:30, or as late in the
workday as possible is probably the best option. You can also set the delay
before restart to up to 30 minutes, so it's conceivable that Windows 2000
users can totally avoid seeing a restart prompt until after 5pm.

(2) In light of (1), enable the "Reschedule Automatic Updates scheduled
installations" policy to ensure that any XP SP2 systems that do not install
at shutdown, or during the scheduled installation, will be forced to install
at powerup the next morning, after the configured delay. Personally I think
the best option for this is "Not Configured" so that the install happens
/one/ minute after powerup, which has the highest likelihood of completing
and restarting, before the user ever gets back from the coffee pot.

(3) In the event that installation at powerup is just not tolerable, you'll
be reliant on late workday installations. In those cases, I would suggest to
seriously consider the use of deadlines after some nominal period of time..
say 7 days after approval. Particularly if you're not able to ensure
installation of updates without some form of user cooperation.

Post by Genessy
Thank you for your help. I had hopes for the reboot having more options
after reading SUS message boards that seemed to think that WSUS would correct
what I see as a problem. Our policy has always been to shut down at night,
or I would have no trouble setting the install and reboot for after hours.
So, unless I want to elevate non-admins, my users may just have to learn
something. I sent out an e-mail before I implemented SUS on the clients, but
my coworkers and I still got dozens of calls. I will give WSUS another
attempt and hope that I can avoid the same conflicts I encountered when
trying to use the release candidate. If I run into trouble again, I will try
your advice. Thanks again.