[Info-vax] Do you (or someone you work with) sysman on Windows?

Tue May 12 18:15:35 EDT 2015

Stephen Hoffman skrev den 2015-05-12 21:23:
> On 2015-05-12 17:46:20 +0000, Steven Schweda said:
>
>>> [...] Why do they always rebuild the system disk from scratch???
>
> With OS X, that's usually an expeditious approach, as you can re-upgrade
> and reinstall OS X over itself, and *not* lose user customizations, nor
> user settings, nor add-on packages.  Very handy for resolving disk
> corruptions — hard disks can have from three to six hard errors per
> terabyte, per some studies.  Hardware RAID or HBVS helps, but not everybody
> has that configured and available.
>
> With OpenVMS, I've found that clean installs have benefits over continuing
> to upgrade ancient system disks, as well.

You mean not to have:

$ prod sho hist openvms
-------------------------- --------- ---------- --- -----------
PRODUCT                    KIT TYPE  OPERATION  VAL DATE
-------------------------- --------- ---------- --- -----------
DEC AXPVMS OPENVMS V8.4    Platform  Install    Sys 29-SEP-2012
DEC AXPVMS OPENVMS V8.3    Platform  Remove      -  29-SEP-2012
DEC AXPVMS OPENVMS V8.3    Platform  Install    (U) 15-OCT-2009
DEC AXPVMS OPENVMS V8.2    Platform  Remove      -  15-OCT-2009
DEC AXPVMS OPENVMS V8.2    Platform  Install        24-APR-2006
DEC AXPVMS OPENVMS V7.3-2  Platform  Remove         24-APR-2006
DEC AXPVMS OPENVMS V7.3-2  Platform  Install        24-APR-2006
DEC AXPVMS OPENVMS V7.2    Platform  Remove         24-APR-2006
DEC AXPVMS OPENVMS V7.2    Platform  Install        11-MAY-1999
DEC AXPVMS OPENVMS V7.1-2  Platform  Remove         11-MAY-1999
DEC AXPVMS OPENVMS V7.1-2  Platform  Install        06-DEC-1998
-------------------------- --------- ---------- --- -----------
11 items found

There is nothing that we have identified as a problem
comming from this, at least.

   There's a whole lot less cruft
> built up in a clean install, and — as you configure the clean install — you
> can create a way to quickly reload the environment, too — akin to the
> cluster-shared files such as SYSUAF and RIGHTSLIST that most are familiar
> with, it can be useful to share SYSTARTUP_VMS.COM and related bits.  This
> means there's a whole lot less of a need to back up the OpenVMS system
> disks, too — occasional backups of the system disk with BACKUP /IMAGE after
> a substantial upgrade, or restore the boot disk from distros (via
> host-based InfoServer, preferably) when necessary.  Keep much more frequent
> copies of the locally-tailored files and the authentication database, etc.
>
>>    I know nothing, but I have a dim memory of trying to transplant a
>> Windows XP disk from one system to a different system -- that is, same
>> OS, different hardware.  The disk initially appeared bootable in the new
>> system, but Windows seemed to have the old hardware path to the disk
>> burned into its brain (somewhere in the Registry? -- I don't know), so it
>> never got beyond the initial step or two, failing with some uninformative
>> error message.
>
> Microsoft Windows has traditionally configured the boot path at install
> time.  This so that the boot-time processing does not have to detect
> hardware and load drivers.   Also so that your licensed version of Windows
> generally stayed with the system that it was licensed with. This is also
> why some vendors of Windows systems specifically for businesses provide
> longer-term hardware compatibility; a way for a business' disk images to be
> used across a variety of hardware that could be acquired over a year or
> two, or so.    With OpenVMS, the boot time processing does detect various
> devices, which means the bootstraps are more complex and are slower.  OS X
> splits the difference here, and caches the last boot sequence as this is
> much faster, but can also be told to boot and configure at boot time.
>
>>    Windows, with its support of nearly unlimited device types, seems to
>> install support for only the immediately required devices on a system
>> during installation, not for all of them.  Thus, moving a disk from one
>> hardware environment to a different one seems to be a major operation.
>
> Older Windows versions could require slipstreaming
> <https://en.wikipedia.org/wiki/Slipstream_(computing)>
> <http://lifehacker.com/how-to-slipstream-windows-updates-into-your-installatio-1562956432>
> or cross-platform deployments
> <https://technet.microsoft.com/en-us/library/hh824993.aspx> to do this, and
> which is more complex but does work.
>
>> Installing Windows from scratch on the new system may _seem_ inefficient,
>> unless you've tried doing it the "easy" way.
>
> Ayup.  If you're deploying a lot of these, it's common to create disk
> images, and deploy to virtual machines or to hardware boxes preferably with
> hardware configuration consistency.  Yes, it is possible to native-boot
> guests, too <https://technet.microsoft.com/en-us/library/hh825689.aspx>
>
> But then most of the above was the result of a few minutes of searching.
> I've not particularly used Microsoft Windows in some time.
>
>