Dustin said:
I'm not entirely sure I agree with disabling windows updates.
Sorry if my reply got misread to imply permanent refusal to accept
Windows updates or even app updates. Disabling their *automatic*
installation is what I meant to address. You decide when the state of
your host changes, not someone else. You investigate the updates to
determine if you will accept them. Provide an escape route should the
updates cause problem before applying the updates. What good is an
update if the behavior you need from the OS or apps becomes unavailable
or they become unusable?
Automatic updates with windows is a security concern. Yes, sometimes
they include new drivers (optional last time I checked) and various
other non security related items.
Hardware updates should NEVER be accepted through Windows Updates. Its
detection scheme is known to be flawed and will offer driver updates
that should NOT be applied to your particular platform. For example,
it took over 3 months for Promise to get Microsoft to yank out an
update after Promise discovered it caused severe problems, even
crashing the OS. Another example is the SATAraid updates for the
SI3112 controller chip. The driver applied depends on which versions
of the SATAraid BIOS are installed on the host. Some drivers are NOT
to be installed in you have a later SATAraid BIOS version than the
driver supports. Yet Windows Updates will tell you that you need a
later version of the driver that not only does not apply to your host
but should never be applied to your host (since there is no need to
flash the BIOS if the hardware is fully functional under your setup, a
newer BIOS version can introduce more problems than it solves, and you
may not be able to update the BIOS version).
NEVER accept hardware updates from Windows Updates. Instead use it
merely as a prompt to have you visit the *manufacturer's* web site to
determine if the updates applies to your hardware and if you are
willing to risk the brain surgery on your host. Also, the direct
manufacturer of the chip may not be the appropriate place to obtain the
driver since the implementation of the chip or ancilliary hardware may
modify the hardware setup where you must use the drivers recommended
by, say, the motherboard maker and NOT the chip maker.
Again, NEVER accept hardware updates from Windows Updates. If the
hardware is working, ignore the suggestion from Windows Updates (you can
even select to never see that suggestion again until you decide to later
unhide the hidden updates). If the hardware is not functioning
correctly or features are not available due to a deficient driver then
use Windows Updates merely as a prompt for you to determine the proper
driver to install. Windows Updates will NOT ensure the suggested driver
is appropriate for your particular platform (hardware+software).
But, they do include security updates that patch (not actually fix in
most cases) an issue they've been told about. While true sometimes a
windows update will cause an IT headache; it's still not something to
be taken lightly or ignored.
But it is something that should be PLANNED ahead and committed *after*
investigation. You can't do that with *automatic* updates.
I have autorun showing as disabled in tweakui on all removable
drives, but if I bring the external power supply online; I'll still
get the autorun window. It's a known windows bug. I suspect the
microsoft patch fixes their ****ed up code. And yes, it's 10 years
too late.
Do not confuse AutoRun with AutoPlay. Those are different functions.
For removable media, the notification of available media will trigger
AutoPlay to present a list of handlers associated with the media type.
One, you are not *running* an exectuable from the removable media.
Two, you are getting *prompted* BEFORE selecting any action, if any,
regarding the removable media.
In TweakUI, with the update, or via registry edits, you can disable the
Auto*RUN* feature of Windows so unknown programs on the removable media
are not automatically executed. AutoPlay is separate. Alas, it is
unfortunate that AutoRun and AutoPlay often get mixed together. It
even happens in TweakUI. I believe even the policies hence the
registry keys also confuse what is AutoRun versus AutoPlay. See:
http://en.wikipedia.org/wiki/AutoRun
AutoPlay is a companion feature of AutoRun. While AutoRun should be
disabled, AutoPlay can remain enabled. Getting prompted based on media
type to select a handler has not yet executed anything from the
removable media. This is very similar to app rules in HIPS where you
get prompted to grant whether or not an so-far-as-yet untrusted program
to load into memory. It's your choice. You actually get a choice.
With AutoRun, you don't get a choice.
AutoPlay is where you get a popup window showing you the various
handlers defined for the object type. AutoRun doesn't prompt you at
all and looks for autorun.inf on the media and will *automatically*
execute the specified executable file.
I haven't investigated on how to disable AutoPlay. One method may be
to de-register all the handlers. While something that Microsoft might
not permit easily, I remembering using some Nirsoft utility to disable
handlers and that probably will also list the AutoPlay handlers. When
you Google on "+disable +autoplay +windows", most of the articles are
actually discussing how to disable autorun. It might be as simple as
using gpedit.msc (not available in Home editions of Windows) which
means also a registry edit where you go to Computer Configuration ->
Administrative Templates -> System and configure the "Turn off
AutoPlay" option. While I have AutoRun disabled using TweakUI (under
its AutoPlay section) or have previously used direct registry edits,
this policy (registry) setting has remained at "Not configured" which
means the default gets used (which means AutoPlay is enabled).
Enabling this policy will turn off AutoPlay. Well, that's how it is
described.
I'm assuming at this point that you aren't really discussing end users
but corp/client configurations?
SRPs can be defined on a non-domain host but that does mean configuring
each host separately rather than pushing out using policies in a
domain. Alas, when I last looked at the registry keys for the SRP
rules, each gets a randomly named key name. You can't just export the
registry key under which the SRPs are defined and then transport to
another host where you run "regedit.exe /s <regfile>". To be fair, I
haven't determined if there is some order to the oddball key name to
see if migration via .reg file was possible but it takes little time to
define the 3-4 path rules for SRP. However, the registry edit to add
the Basic (limited) account is just a registry entry that can be
installed easily using a .reg file (and I'm guessing could also be
pushed via policy).
Policies are nothing more than registry entries. If you are granted
admin privileges to your workstation (i.e., to your host in the domain)
or are logging on locally as an admin then you can always undo these
policies. For example, my company has a global policy that the
screensaver will activate after 15 minutes of idle time. The
screensaver will lock the workstation. This was unacceptable on a
shared host where physical access was controlled and where we wanted
users some access to a limited set of programs but never wanted them to
login (initially or to get out of screensaver mode). Those of us that
admin'ed that host were allowed admin privileges to that host (i.e., we
has Administrators rights on the host where we logged in, not admin
rights to the PDC or elsewhere we were not allowed to login). To get
around the screensaver problem, a login script was used (although other
startup locations could have been used) that simply ran "regedit.exe /s
<regfile>". The policies get pushed out at login but the script or
startup for the .reg file can undo those policies if the user logs in
under an admin-level account. Policies are just registry entries. If
you have admin rights on the host, you can undo the policies. While I
may mention using gpedit.msc, it's just a convenient means of editing
the registry instead of using regedit.exe.
