1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

XP NTBackup with NT 3.50

Discussion in 'Windows XP' started by jjjdavidson, May 5, 2010.

  1. jjjdavidson

    jjjdavidson Flightless Bird

    Our network has one elderly NT 3.50 workstation named LASER1 (running
    proprietary CNC software). I've long been running weekly backups of critical
    files on LASER1. On a nearby XP workstation, I map a drive (U:) to a network
    share on LASER1, then use XP's NTBackup. For six years it's run without any
    serious problems.

    Three weeks ago the XP workstation's backup log reported, "The network disk
    drive has stopped responding. Backup set aborted." The next week it did the
    same thing. Both times, the backup file was obviously much too small for the
    backup to have been successful.

    Last week, NTBackup instead logged messages like, "Could not access portions
    of file U:/100HOLES.CNC. You may not have permission to open the file, or the
    file may be missing or damaged," apparently for all 6000 files and
    directories on LASER1. However, the backup file size went back up to normal.

    Manually running the backup job today, I again got "Could not access
    portions" messages for everything, with a normal-sized backup file. A test
    restore apparently could retrieve all of the LASER1 files successfully;
    Windiff showed no differences between existing files on LASER1 and the
    test-restored files. But since the backup itself got errors, the verify step
    was never run.

    Connecting to LASER1 over the network, I can read any desired file normally.

    Any idea what's suddenly causing these errors, and how to get rid of them?
    NT 3.50 on LASER1 never gets updated; the XP workstation running NTBackup had
    the April Microsoft security updates installed the morning before the first
    backup failed.

    Thanks!
     
  2. Andrew McLaren

    Andrew McLaren Flightless Bird

    Hi jjjdavidson

    I didn't see any other replies, so here's my 2 cents ...

    This error message from NTBackup is fairly common and usually happens
    when there is some kind of problem in the SMB network session to the
    mapped drive. To say what the problem is exactly, you'd probably need to
    get a network trace, using Microsoft NetMon or Wireshark. These are both
    free downloads; and fairly easy to use if you have a background in
    networking. Otherwise they may be a bit opaque ....

    Because the problem started after the April security fixes were applied
    to the XP machine, they would seem to be implicated - perhaps they
    enforce a more rigorous behaviour which the old NT 3.5 machine cannot
    comply with (I've seen this with many security patches in the past). One
    workaround would be to uninstall the security patch from the XP machine
    - but, I don't really recommend that.

    An alternative workaround might be to XCOPY the files from the U: drive
    to the local XP machine (since this seems to work okay) and then back
    them up from there. In the case of a restore, you'd XCOPY the files back
    across to the NT 3.5 machine. Not a perfect solution but it might keep
    you going.

    Nice to see a NT 3.5 machine still running, out there ... it was a
    classic OS!

    Hope this helps a bit,

    Andrew

    --
    amclar at optusnet dot com dot au



    On 6/05/2010 06:29, jjjdavidson wrote:
    > Our network has one elderly NT 3.50 workstation named LASER1 (running
    > proprietary CNC software). I've long been running weekly backups of critical
    > files on LASER1. On a nearby XP workstation, I map a drive (U:) to a network
    > share on LASER1, then use XP's NTBackup. For six years it's run without any
    > serious problems.
    >
    > Three weeks ago the XP workstation's backup log reported, "The network disk
    > drive has stopped responding. Backup set aborted." The next week it did the
    > same thing. Both times, the backup file was obviously much too small for the
    > backup to have been successful.
    >
    > Last week, NTBackup instead logged messages like, "Could not access portions
    > of file U:/100HOLES.CNC. You may not have permission to open the file, or the
    > file may be missing or damaged," apparently for all 6000 files and
    > directories on LASER1. However, the backup file size went back up to normal.
    >
    > Manually running the backup job today, I again got "Could not access
    > portions" messages for everything, with a normal-sized backup file. A test
    > restore apparently could retrieve all of the LASER1 files successfully;
    > Windiff showed no differences between existing files on LASER1 and the
    > test-restored files. But since the backup itself got errors, the verify step
    > was never run.
    >
    > Connecting to LASER1 over the network, I can read any desired file normally.
    >
    > Any idea what's suddenly causing these errors, and how to get rid of them?
    > NT 3.50 on LASER1 never gets updated; the XP workstation running NTBackup had
    > the April Microsoft security updates installed the morning before the first
    > backup failed.
    >
    > Thanks!
     
  3. jjjdavidson

    jjjdavidson Flightless Bird

    Yes, it was a classic. Even though I miss my right mouse button, I love the
    stability. In _eleven years_ I've never seen that workstation crash once.
    But it has never played well with Win2K and later.

    I read up on all the April patches and found that KB980232 updates the SMB
    client. Googling for problems, I'm not alone (apparently a lot of people
    still run NT4.0 servers):

    http://social.technet.microsoft.com...n/thread/bae1e32a-b878-4af2-8d27-9b747e11bf21
    http://social.answers.microsoft.com/Forums/en/vistawu/thread/fc1669c5-2e30-4207-8fe2-54a54f02679a

    This appears to be a pretty broad problem with KB980232 and pre-Win2K
    systems. It seems the files can be read just fine (hence my usable backups)
    but the ACLs are inaccessible. That's the second patch in three months
    (KB978037 zombie windows) to break something on my systems--unprecedented.

    Thanks for the input. For the time being, I probably will have to update my
    batch job to run an XCOPY (uninstalling KB980232 seems excessive).

    "Andrew McLaren" wrote:

    > Hi jjjdavidson
    >
    > I didn't see any other replies, so here's my 2 cents ...
    >
    > This error message from NTBackup is fairly common and usually happens
    > when there is some kind of problem in the SMB network session to the
    > mapped drive. To say what the problem is exactly, you'd probably need to
    > get a network trace, using Microsoft NetMon or Wireshark. These are both
    > free downloads; and fairly easy to use if you have a background in
    > networking. Otherwise they may be a bit opaque ....
    >
    > Because the problem started after the April security fixes were applied
    > to the XP machine, they would seem to be implicated - perhaps they
    > enforce a more rigorous behaviour which the old NT 3.5 machine cannot
    > comply with (I've seen this with many security patches in the past). One
    > workaround would be to uninstall the security patch from the XP machine
    > - but, I don't really recommend that.
    >
    > An alternative workaround might be to XCOPY the files from the U: drive
    > to the local XP machine (since this seems to work okay) and then back
    > them up from there. In the case of a restore, you'd XCOPY the files back
    > across to the NT 3.5 machine. Not a perfect solution but it might keep
    > you going.
    >
    > Nice to see a NT 3.5 machine still running, out there ... it was a
    > classic OS!
    >
    > Hope this helps a bit,
    >
    > Andrew
    >
    > --
    > amclar at optusnet dot com dot au
    >
    >
    >
    > On 6/05/2010 06:29, jjjdavidson wrote:
    > > Our network has one elderly NT 3.50 workstation named LASER1 (running
    > > proprietary CNC software). I've long been running weekly backups of critical
    > > files on LASER1. On a nearby XP workstation, I map a drive (U:) to a network
    > > share on LASER1, then use XP's NTBackup. For six years it's run without any
    > > serious problems.
    > >
    > > Three weeks ago the XP workstation's backup log reported, "The network disk
    > > drive has stopped responding. Backup set aborted." The next week it did the
    > > same thing. Both times, the backup file was obviously much too small for the
    > > backup to have been successful.
    > >
    > > Last week, NTBackup instead logged messages like, "Could not access portions
    > > of file U:/100HOLES.CNC. You may not have permission to open the file, or the
    > > file may be missing or damaged," apparently for all 6000 files and
    > > directories on LASER1. However, the backup file size went back up to normal.
    > >
    > > Manually running the backup job today, I again got "Could not access
    > > portions" messages for everything, with a normal-sized backup file. A test
    > > restore apparently could retrieve all of the LASER1 files successfully;
    > > Windiff showed no differences between existing files on LASER1 and the
    > > test-restored files. But since the backup itself got errors, the verify step
    > > was never run.
    > >
    > > Connecting to LASER1 over the network, I can read any desired file normally.
    > >
    > > Any idea what's suddenly causing these errors, and how to get rid of them?
    > > NT 3.50 on LASER1 never gets updated; the XP workstation running NTBackup had
    > > the April Microsoft security updates installed the morning before the first
    > > backup failed.
    > >
    > > Thanks!

    >
    > .
    >
     
  4. jjjdavidson

    jjjdavidson Flightless Bird

    I was able to modify my backup batch file to use XCOPY - with one
    qualification. I can't use the XCOPY /O or /X parameters to copy owner, ACL,
    or audit settings. Apparently KB980232 improves the SMB client's handling of
    ACLs or other security information on files - improves it to the point that
    NT3.5 and NT4.0 can't talk to XP any more.

    One of the Technet threads I found mentions today that a hotfix might come
    out soon. X'd fingers.

    "jjjdavidson" wrote:

    > Yes, it was a classic. Even though I miss my right mouse button, I love the
    > stability. In _eleven years_ I've never seen that workstation crash once.
    > But it has never played well with Win2K and later.
    >
    > I read up on all the April patches and found that KB980232 updates the SMB
    > client. Googling for problems, I'm not alone (apparently a lot of people
    > still run NT4.0 servers):
    >
    > http://social.technet.microsoft.com...n/thread/bae1e32a-b878-4af2-8d27-9b747e11bf21
    > http://social.answers.microsoft.com/Forums/en/vistawu/thread/fc1669c5-2e30-4207-8fe2-54a54f02679a
    >
    > This appears to be a pretty broad problem with KB980232 and pre-Win2K
    > systems. It seems the files can be read just fine (hence my usable backups)
    > but the ACLs are inaccessible. That's the second patch in three months
    > (KB978037 zombie windows) to break something on my systems--unprecedented.
    >
    > Thanks for the input. For the time being, I probably will have to update my
    > batch job to run an XCOPY (uninstalling KB980232 seems excessive).
    >
    > "Andrew McLaren" wrote:
    >
    > > Hi jjjdavidson
    > >
    > > I didn't see any other replies, so here's my 2 cents ...
    > >
    > > This error message from NTBackup is fairly common and usually happens
    > > when there is some kind of problem in the SMB network session to the
    > > mapped drive. To say what the problem is exactly, you'd probably need to
    > > get a network trace, using Microsoft NetMon or Wireshark. These are both
    > > free downloads; and fairly easy to use if you have a background in
    > > networking. Otherwise they may be a bit opaque ....
    > >
    > > Because the problem started after the April security fixes were applied
    > > to the XP machine, they would seem to be implicated - perhaps they
    > > enforce a more rigorous behaviour which the old NT 3.5 machine cannot
    > > comply with (I've seen this with many security patches in the past). One
    > > workaround would be to uninstall the security patch from the XP machine
    > > - but, I don't really recommend that.
    > >
    > > An alternative workaround might be to XCOPY the files from the U: drive
    > > to the local XP machine (since this seems to work okay) and then back
    > > them up from there. In the case of a restore, you'd XCOPY the files back
    > > across to the NT 3.5 machine. Not a perfect solution but it might keep
    > > you going.
    > >
    > > Nice to see a NT 3.5 machine still running, out there ... it was a
    > > classic OS!
    > >
    > > Hope this helps a bit,
    > >
    > > Andrew
    > >
    > > --
    > > amclar at optusnet dot com dot au
    > >
    > >
    > >
    > > On 6/05/2010 06:29, jjjdavidson wrote:
    > > > Our network has one elderly NT 3.50 workstation named LASER1 (running
    > > > proprietary CNC software). I've long been running weekly backups of critical
    > > > files on LASER1. On a nearby XP workstation, I map a drive (U:) to a network
    > > > share on LASER1, then use XP's NTBackup. For six years it's run without any
    > > > serious problems.
    > > >
    > > > Three weeks ago the XP workstation's backup log reported, "The network disk
    > > > drive has stopped responding. Backup set aborted." The next week it did the
    > > > same thing. Both times, the backup file was obviously much too small for the
    > > > backup to have been successful.
    > > >
    > > > Last week, NTBackup instead logged messages like, "Could not access portions
    > > > of file U:/100HOLES.CNC. You may not have permission to open the file, or the
    > > > file may be missing or damaged," apparently for all 6000 files and
    > > > directories on LASER1. However, the backup file size went back up to normal.
    > > >
    > > > Manually running the backup job today, I again got "Could not access
    > > > portions" messages for everything, with a normal-sized backup file. A test
    > > > restore apparently could retrieve all of the LASER1 files successfully;
    > > > Windiff showed no differences between existing files on LASER1 and the
    > > > test-restored files. But since the backup itself got errors, the verify step
    > > > was never run.
    > > >
    > > > Connecting to LASER1 over the network, I can read any desired file normally.
    > > >
    > > > Any idea what's suddenly causing these errors, and how to get rid of them?
    > > > NT 3.50 on LASER1 never gets updated; the XP workstation running NTBackup had
    > > > the April Microsoft security updates installed the morning before the first
    > > > backup failed.
    > > >
    > > > Thanks!

    > >
    > > .
    > >
     
  5. Andrew McLaren

    Andrew McLaren Flightless Bird

    Thanks, that's interesting info ...

    I'm not sure exactly which of the 980232 vulnerabilities is in play
    here. But I'd guess the NT 3.5 machine is returning a SMB packet to XP,
    which has "incomplete" information in one of the headers; and hence
    resembles a malformed or malicious SMB assault. In the relatively lax
    world of NT 3.5 that was acceptable; but in the more rigorous world of
    contemporary XP, that is no longer acceptable. So XP now rejects some
    packet which NT 3.5 sends back to it, during the NTbackup. It seems to
    affect ACL data ... which is a bummer, in your context.

    The "CNC software" may be CAD/CAM? Masterware?? If so, may be time to
    (reluctantly) upgrade??? I'm sure they have lots of whizz-bang features
    in their latest version :) Anyways, good luck with it ...

    Cheers,

    Andrew
    Sydney Australia


    On 8/05/2010 06:13, jjjdavidson wrote:
    > I was able to modify my backup batch file to use XCOPY - with one
    > qualification. I can't use the XCOPY /O or /X parameters to copy owner, ACL,
    > or audit settings. Apparently KB980232 improves the SMB client's handling of
    > ACLs or other security information on files - improves it to the point that
    > NT3.5 and NT4.0 can't talk to XP any more.
    >
    > One of the Technet threads I found mentions today that a hotfix might come
    > out soon. X'd fingers.
    >
    > "jjjdavidson" wrote:
    >
    >> Yes, it was a classic. Even though I miss my right mouse button, I love the
    >> stability. In _eleven years_ I've never seen that workstation crash once.
    >> But it has never played well with Win2K and later.
    >>
    >> I read up on all the April patches and found that KB980232 updates the SMB
    >> client. Googling for problems, I'm not alone (apparently a lot of people
    >> still run NT4.0 servers):
    >>
    >> http://social.technet.microsoft.com...n/thread/bae1e32a-b878-4af2-8d27-9b747e11bf21
    >> http://social.answers.microsoft.com/Forums/en/vistawu/thread/fc1669c5-2e30-4207-8fe2-54a54f02679a
    >>
    >> This appears to be a pretty broad problem with KB980232 and pre-Win2K
    >> systems. It seems the files can be read just fine (hence my usable backups)
    >> but the ACLs are inaccessible. That's the second patch in three months
    >> (KB978037 zombie windows) to break something on my systems--unprecedented.
    >>
    >> Thanks for the input. For the time being, I probably will have to update my
    >> batch job to run an XCOPY (uninstalling KB980232 seems excessive).
    >>
    >> "Andrew McLaren" wrote:
    >>
    >>> Hi jjjdavidson
    >>>
    >>> I didn't see any other replies, so here's my 2 cents ...
    >>>
    >>> This error message from NTBackup is fairly common and usually happens
    >>> when there is some kind of problem in the SMB network session to the
    >>> mapped drive. To say what the problem is exactly, you'd probably need to
    >>> get a network trace, using Microsoft NetMon or Wireshark. These are both
    >>> free downloads; and fairly easy to use if you have a background in
    >>> networking. Otherwise they may be a bit opaque ....
    >>>
    >>> Because the problem started after the April security fixes were applied
    >>> to the XP machine, they would seem to be implicated - perhaps they
    >>> enforce a more rigorous behaviour which the old NT 3.5 machine cannot
    >>> comply with (I've seen this with many security patches in the past). One
    >>> workaround would be to uninstall the security patch from the XP machine
    >>> - but, I don't really recommend that.
    >>>
    >>> An alternative workaround might be to XCOPY the files from the U: drive
    >>> to the local XP machine (since this seems to work okay) and then back
    >>> them up from there. In the case of a restore, you'd XCOPY the files back
    >>> across to the NT 3.5 machine. Not a perfect solution but it might keep
    >>> you going.
    >>>
    >>> Nice to see a NT 3.5 machine still running, out there ... it was a
    >>> classic OS!
    >>>
    >>> Hope this helps a bit,
    >>>
    >>> Andrew
    >>>
    >>> --
    >>> amclar at optusnet dot com dot au
    >>>
    >>>
    >>>
    >>> On 6/05/2010 06:29, jjjdavidson wrote:
    >>>> Our network has one elderly NT 3.50 workstation named LASER1 (running
    >>>> proprietary CNC software). I've long been running weekly backups of critical
    >>>> files on LASER1. On a nearby XP workstation, I map a drive (U:) to a network
    >>>> share on LASER1, then use XP's NTBackup. For six years it's run without any
    >>>> serious problems.
    >>>>
    >>>> Three weeks ago the XP workstation's backup log reported, "The network disk
    >>>> drive has stopped responding. Backup set aborted." The next week it did the
    >>>> same thing. Both times, the backup file was obviously much too small for the
    >>>> backup to have been successful.
    >>>>
    >>>> Last week, NTBackup instead logged messages like, "Could not access portions
    >>>> of file U:/100HOLES.CNC. You may not have permission to open the file, or the
    >>>> file may be missing or damaged," apparently for all 6000 files and
    >>>> directories on LASER1. However, the backup file size went back up to normal.
    >>>>
    >>>> Manually running the backup job today, I again got "Could not access
    >>>> portions" messages for everything, with a normal-sized backup file. A test
    >>>> restore apparently could retrieve all of the LASER1 files successfully;
    >>>> Windiff showed no differences between existing files on LASER1 and the
    >>>> test-restored files. But since the backup itself got errors, the verify step
    >>>> was never run.
    >>>>
    >>>> Connecting to LASER1 over the network, I can read any desired file normally.
    >>>>
    >>>> Any idea what's suddenly causing these errors, and how to get rid of them?
    >>>> NT 3.50 on LASER1 never gets updated; the XP workstation running NTBackup had
    >>>> the April Microsoft security updates installed the morning before the first
    >>>> backup failed.
    >>>>
    >>>> Thanks!
    >>>
    >>> .
    >>>
     
  6. jjjdavidson

    jjjdavidson Flightless Bird

    It took a little while, but Microsoft got out a hotfix for this problem:

    http://support.microsoft.com/KB/983458

    I've been running the hotfix for a couple of weeks now and XP/NT
    communication seems to be working correctly again. Thanks for your help!

    "Andrew McLaren" wrote:

    > Thanks, that's interesting info ...
    >
    > I'm not sure exactly which of the 980232 vulnerabilities is in play
    > here. But I'd guess the NT 3.5 machine is returning a SMB packet to XP,
    > which has "incomplete" information in one of the headers; and hence
    > resembles a malformed or malicious SMB assault. In the relatively lax
    > world of NT 3.5 that was acceptable; but in the more rigorous world of
    > contemporary XP, that is no longer acceptable. So XP now rejects some
    > packet which NT 3.5 sends back to it, during the NTbackup. It seems to
    > affect ACL data ... which is a bummer, in your context.
    >
    > The "CNC software" may be CAD/CAM? Masterware?? If so, may be time to
    > (reluctantly) upgrade??? I'm sure they have lots of whizz-bang features
    > in their latest version :) Anyways, good luck with it ...
    >
    > Cheers,
    >
    > Andrew
    > Sydney Australia
    >
    >
    > On 8/05/2010 06:13, jjjdavidson wrote:
    > > I was able to modify my backup batch file to use XCOPY - with one
    > > qualification. I can't use the XCOPY /O or /X parameters to copy owner, ACL,
    > > or audit settings. Apparently KB980232 improves the SMB client's handling of
    > > ACLs or other security information on files - improves it to the point that
    > > NT3.5 and NT4.0 can't talk to XP any more.
    > >
    > > One of the Technet threads I found mentions today that a hotfix might come
    > > out soon. X'd fingers.
    > >
    > > "jjjdavidson" wrote:
    > >
    > >> Yes, it was a classic. Even though I miss my right mouse button, I love the
    > >> stability. In _eleven years_ I've never seen that workstation crash once.
    > >> But it has never played well with Win2K and later.
    > >>
    > >> I read up on all the April patches and found that KB980232 updates the SMB
    > >> client. Googling for problems, I'm not alone (apparently a lot of people
    > >> still run NT4.0 servers):
    > >>
    > >> http://social.technet.microsoft.com...n/thread/bae1e32a-b878-4af2-8d27-9b747e11bf21
    > >> http://social.answers.microsoft.com/Forums/en/vistawu/thread/fc1669c5-2e30-4207-8fe2-54a54f02679a
    > >>
    > >> This appears to be a pretty broad problem with KB980232 and pre-Win2K
    > >> systems. It seems the files can be read just fine (hence my usable backups)
    > >> but the ACLs are inaccessible. That's the second patch in three months
    > >> (KB978037 zombie windows) to break something on my systems--unprecedented.
    > >>
    > >> Thanks for the input. For the time being, I probably will have to update my
    > >> batch job to run an XCOPY (uninstalling KB980232 seems excessive).
    > >>
    > >> "Andrew McLaren" wrote:
    > >>
    > >>> Hi jjjdavidson
    > >>>
    > >>> I didn't see any other replies, so here's my 2 cents ...
    > >>>
    > >>> This error message from NTBackup is fairly common and usually happens
    > >>> when there is some kind of problem in the SMB network session to the
    > >>> mapped drive. To say what the problem is exactly, you'd probably need to
    > >>> get a network trace, using Microsoft NetMon or Wireshark. These are both
    > >>> free downloads; and fairly easy to use if you have a background in
    > >>> networking. Otherwise they may be a bit opaque ....
    > >>>
    > >>> Because the problem started after the April security fixes were applied
    > >>> to the XP machine, they would seem to be implicated - perhaps they
    > >>> enforce a more rigorous behaviour which the old NT 3.5 machine cannot
    > >>> comply with (I've seen this with many security patches in the past). One
    > >>> workaround would be to uninstall the security patch from the XP machine
    > >>> - but, I don't really recommend that.
    > >>>
    > >>> An alternative workaround might be to XCOPY the files from the U: drive
    > >>> to the local XP machine (since this seems to work okay) and then back
    > >>> them up from there. In the case of a restore, you'd XCOPY the files back
    > >>> across to the NT 3.5 machine. Not a perfect solution but it might keep
    > >>> you going.
    > >>>
    > >>> Nice to see a NT 3.5 machine still running, out there ... it was a
    > >>> classic OS!
    > >>>
    > >>> Hope this helps a bit,
    > >>>
    > >>> Andrew
    > >>>
    > >>> --
    > >>> amclar at optusnet dot com dot au
    > >>>
    > >>>
    > >>>
    > >>> On 6/05/2010 06:29, jjjdavidson wrote:
    > >>>> Our network has one elderly NT 3.50 workstation named LASER1 (running
    > >>>> proprietary CNC software). I've long been running weekly backups of critical
    > >>>> files on LASER1. On a nearby XP workstation, I map a drive (U:) to a network
    > >>>> share on LASER1, then use XP's NTBackup. For six years it's run without any
    > >>>> serious problems.
    > >>>>
    > >>>> Three weeks ago the XP workstation's backup log reported, "The network disk
    > >>>> drive has stopped responding. Backup set aborted." The next week it did the
    > >>>> same thing. Both times, the backup file was obviously much too small for the
    > >>>> backup to have been successful.
    > >>>>
    > >>>> Last week, NTBackup instead logged messages like, "Could not access portions
    > >>>> of file U:/100HOLES.CNC. You may not have permission to open the file, or the
    > >>>> file may be missing or damaged," apparently for all 6000 files and
    > >>>> directories on LASER1. However, the backup file size went back up to normal.
    > >>>>
    > >>>> Manually running the backup job today, I again got "Could not access
    > >>>> portions" messages for everything, with a normal-sized backup file. A test
    > >>>> restore apparently could retrieve all of the LASER1 files successfully;
    > >>>> Windiff showed no differences between existing files on LASER1 and the
    > >>>> test-restored files. But since the backup itself got errors, the verify step
    > >>>> was never run.
    > >>>>
    > >>>> Connecting to LASER1 over the network, I can read any desired file normally.
    > >>>>
    > >>>> Any idea what's suddenly causing these errors, and how to get rid of them?
    > >>>> NT 3.50 on LASER1 never gets updated; the XP workstation running NTBackup had
    > >>>> the April Microsoft security updates installed the morning before the first
    > >>>> backup failed.
    > >>>>
    > >>>> Thanks!
    > >>>
    > >>> .
    > >>>

    >
    > .
    >
     

Share This Page