Daylight Savings Time reminder for Windows NT/2000 users

REMINDER: a Daylight Savings Time problem was discovered in October 2000
with the TSM Windows NT/2000 V3.7.2, V4.1.0, and V4.1.1 clients. It has
been fixed in patches, maintenance, and new versions of the clients for
the past year. Before the time changes at the end of October, please be
sure you installed one of the following versions of the Windows NT/2000
client in the past year to avoid the problem:

3.7.2.18*
3.7.2.19*
4.1.1.16
4.1.2 and above

Details of the original problem can be found in this Flash

* V3.7 client service support ends on October 31, 2001. We recommend
upgrading to the V4.1.3 client instead of installing one of these patches.


IMPORTANT - PLEASE READ THE FOLLOWING:

 A problem with the switch between Daylight Savings Time (DST) and
Standard
 Time (STD) was discovered in October 2000 for the TSM Windows NT/2000
 clients.


 BACKGROUND

 When Windows NT and 2000 systems automatically switch between DST and
STD,
 the time attributes for files stored on NTFS file systems will be shifted
 by one hour. This is because NTFS displays time information as an offset
 from Greenwich Mean Time (GMT). Thus when the DST change is made, the
 offset from GMT is changed, causing the timestamps on your NTFS files to
 also change. (Note: Time information for Event Viewer events is affected
in
 the same manner, but that is not pertinent to this discussion.) Further
 information on this subject is available in the Microsoft Knowledge Base,
 item Q129574. If you point your web browser to Microsoft's MSDN site,
 http://msdn.microsoft.com, and search on "Q129574" (without the quotes),
 you will find the information.



 THE PROBLEM

 When the system automatically adjusts between DST and STD, the TSM
3.7.2.0
 through 3.7.2.16 clients, and the TSM 4.1.0.x and 4.1.1.0 clients will
see
 that the modification time has changed for all files on NTFS systems, and
 will proceed to back everything up accordingly, even if the file has not
 really changed. This will occur only once after the time change, and
 thereafter incremental backups will proceed as normal. However, this will
 almost certainly affect the amount of data backed up by each client,
 effectively causing a full backup on all NTFS file systems. This could
have a
 large impact on network and TSM server resources.

 The following bullets summarize the conditions under which this problem
can
 occur:

 - TSM client is running on Windows NT 4.0 or Windows 2000. TSM clients
 running on Windows 9x-based operating systems (Windows 95, 98) are not
 affected.

 - The TSM client level is 3.7.2.0 through 3.7.2.16, 4.1.0.x, or 4.1.1.0.
TSM
   client levels below 3.7.2.x are not affected, as the problem was
introduced
   in the 3.7.2.x code, and client levels at 4.1.2 and above are not
affected,
   as the problem was fixed in those clients.

 - The file systems are formatted for NTFS. FAT and FAT32 file systems are
   unaffected by this problem.

 - The operating system's time zone settings are configured to
automatically
   adjust for DST. You can check this by right-clicking on the Windows
task
   bar and selecting the "Adjust Date/Time" item in the pop-up menu.
   (Alternatively, you can double-click on the clock display in the task
bar.)
   Either of these actions will bring up the "Date/Time Properties"
dialog.
   Click on the "Time Zone" tab and you should see the "Automatically
adjust
   clock for daylight saving changes" checkbox. If the box is checked (the
   default installation setting), then your system is configured to
   automatically adjust for DST. Users in regions that do not observe DST
   (such as Arizona) will be unaffected by this problem, provided that the
   system's time zone settings are similarly configured to not observe
DST.



 WHAT IBM/TIVOLI IS DOING ABOUT THIS

 Here are the actions that we are taking or have taken to date:

 1) We have opened a severity 1 APAR, IC28544, to address this problem,
and
    fixed it in the V4.1.2 and higher clients. These clients are the
preferred
    maintenance for this fix, and can be downloaded from the Tivoli TSM
    support web page at
    http://www.tivoli.com/support/storage_mgr/clients.html#nt2k.

 2) We have designed and built fixtests for the 3.7.2 and 4.1.1 Windows
    clients. The fixtest version numbers are 3.7.2.18, 3.7.2.19 (preferred
    over 3.7.2.18) and 4.1.1.16. The fixtests are available on the
anonymous
    FTP server ftp.software.ibm.com in the following locations:

    Version 4.1.1.16:

       Directory

/storage/tivoli-storage-management/patches/client/v4r1/Windows/v411/single

       Package name starts with: IP22088_16


    V3.7 PTF 2:

       Directory (Intel)

/storage/tivoli-storage-management/patches/client/v3r7/Windows/v372/i386/single

       Package names start with: IP21933_18 and IP21933_19

       Directory (DEC Alpha)
 /storage/tivoli-storage-management/patches/client/v3r7/Windows/v372/alpha

       Package name starts with: IP21934_19


 3) We have documented circumventions for this problem (see below).

 4) We are working on notifying all of our customers in the most expedient
    manner possible.

 5) We are continuing our escape and root-cause analyses in order to
prevent
    this kind of problem from happening again.



 CIRCUMVENTIONS

 1) Lock all client nodes to prevent access to the TSM server. After the
    fixtest has been applied to each system, unlock that system's node(s).
    Since many nodes may be affected, a batch script may be helpful in
    facilitating the locking and unlocking of the nodes.

 2) If the fixtest can not yet be applied, consider using the -INCRBYDATE
    option to back up the clients. The easiest way to do this is to add it
to
    existing schedules' options setting via the UPDATE SCHEDULE
administrator
    command. Example:

       UPDATE SCHEDULE STANDARD DAILY OPTIONS="-INCRBYDATE"

    or if your schedule already contains options, such as -SUBDIR=YES:

       UPDATE SCHEDULE STANDARD DAILY OPTIONS="-INCRBYDATE -SUBDIR=YES"

    Please refer to the Tivoli Storage Manager Administrator's Reference
for
    further information on the UPDATE SCHEDULE command.

    Please refer to the Tivoli Storage Manager for Windows Using the
Windows
    Backup-Archive Client for further information on the -INCRBYDATE
option.

 3) Same as #1 above, except instead of locking each node, disable all
client
    sessions on the TSM server. This is easier than having to lock and
unlock
    each node, but would require that all affected systems have the
fixtest
    applied before re-enabling the server for client sessions.

 4) Shut down your TSM server(s) until all affected systems can have the
    fixtest applied.

 5) If the additional network and TSM server overhead is not a concern,
you
    can just let the backups run to completion. However, because this can
    cause unchanged files to be backed up, the oldest version of each
affected
    file will be expired. In order to avoid premature expiration, you may
wish
    to add '1' to each backup copygroup's VEREXISTS setting. For example,
if
    VEREXISTS is currently set to '15', you may wish to change it to '16'.
Use
    the UPDATE COPYGROUP and ACTIVATE POLICYSET commands to implement this
    change. Example:

       UPDATE COPYGROUP STANDARD STANDARD STANDARD STANDARD VEREXISTS=16
       ACTIVATE POLICYSET STANDARD STANDARD

    Please refer to the Tivoli Storage Manager Administrator's Reference
for
    further information on the UPDATE COPYGROUP and ACTIVATE POLICYSET
    commands.


 We apologize for the inconveniences caused by this problem.


Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.