Hello
did I had to install the fix IP22088_17 on the NT/2000 servers, before next
week'end, where we are going to summertime???
Sincerely,
Bo Nielsen
FDB data Phone: +45 4386 4671
Roskildevej 65 Fax: +45 4386 4990
DK-2620 Albertslund E-mail: bo_nielsen AT fdb DOT dk
Denmark
> ----------
> Fra: Andy Raibeck[SMTP:Andrew_Raibeck AT TIVOLI DOT COM]
> Svar til: ADSM: Dist Stor Manager
> Sendt: 28. oktober 2000 08:44
> Til: ADSM-L AT VM.MARIST DOT EDU
> Emne: Re: ATTN ALL TSM USERS: Windows NT/2000 Daylight Savings
> Time Problem
>
> Hello,
>
> The fixtests for this problem are now available for download from the FTP
> site.
>
> Please note that the original note I sent out earlier erroneously stated
> that the version 4.1 fixtest was 4.1.1.17 and the file names to download
> begin wtih IP22088_17. In fact, the fixtest version is 4.1.1.16 and the
> file names begin with IP22088_16. The 3.7 fixtest was reported correctly
> as
> being version 3.7.2.17 and the file names beginning with IP21933_17. I
> have
> included the corrected version of the original note below for your
> reference.
>
> The files are located on our anonymous ftp site, ftp.software.ibm.com:
>
> Version 4.1.1.16:
>
> Directory
> /storage/tivoli-storage-management/patches/client/v4r1/Windows/v411/single
>
> Please review the IP22088_16_readme.ftp file for information on
> downloading
> and installing the fixtest.
>
>
>
> Version 3.7.2.17:
>
> Directory
> /storage/tivoli-storage-management/patches/client/v3r7/Windows/v372/i386/s
> ingle
>
> Please review the IP21933_17_readme.ftp file for information on
> downloading
> and installing the fixtest.
>
>
>
> Andy
>
> Andy Raibeck
> IBM/Tivoli
> Tivoli Storage Manager Client Development
> e-mail: andrew.raibeck AT tivoli DOT com
> "The only dumb question is the one that goes unasked."
>
> IMPORTANT - PLEASE READ THE FOLLOWING:
>
> A problem with the switch between Daylight Savings Time (DST) and Standard
> Time (STD) has just been discovered for the Windows TSM 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
> (and higher) 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.x or higher (including all 4.1.x levels).
> TSM client levels below 3.7.2.x are not affected, as the problem was
> introduced in the 3.7.2.x code.
>
> - 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.
>
> 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.17 and 4.1.1.16. The
> fixtests should be available in a little while. They will be posted to 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 start with: IP22088_16
>
>
> V3.7 PTF 2:
>
> Directory
> /storage/tivoli-storage-management/patches/client/v3r7/Windows/v372/i386/s
> ingle
>
>
> Package name starts with: IP21933_17
>
>
> A follow-up note will be posted when the fixtests are actually available
> for download.
>
> 3) Even with the availability of a fixtest, most customers will be unable
> to roll it out in time for the time change. We have documented
> circumventions for this problem (see below), as the DST to STD switch is
> this weekend.
>
> 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
>
> Here are the known circumventions available thus far:
>
> 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.
>
> Sincerely,
>
> Andy Raibeck
>
> IBM/Tivoli
> Tivoli Storage Manager Client Development
> e-mail: andrew.raibeck AT tivoli DOT com
> "The only dumb question is the one that goes unasked."
>
|
