Network goes (partly) to sleep!

don't know how to describe it any better.

I suspect this is a Windows problem not a Novell/OES problem but I'm hoping someone here has seen similar behaviour and knows the simple tweak that will fix it.

Here's the symptom that alerted me to the problem.

We have two servers running. One is the actual working server. The other is a complete mirror of the first, updated daily with a complete backup of 1 to 2.
That system has been working reliably for 5 years.

Since I rebuilt my Windows workstation (to version 1803) a couple of weeks ago, which contains and runs the backup software, I've seen this unusual behaviour.

After the rebuild, it worked for the first week or so.

Came in this morning and noticed that it had failed, with the backup software showing that it had been unable to access the reserve network.

Fired up my file browser and I found that I too could not access any of the partitions on the second server.

I was about to restart the server but I took a look at it and it looked completely normal and I couldn't see any faults logged.

So I went back to my file browser and, instead of trying to read a partition on the second server, I just typed in the root. That came up as normal, showing all the partitions, all of which were now accessible. Problem solved.

Except that I have no idea why they became inaccessible in the first place and I'd rather it didn't happen again! It looks like some kind windows timeout (a bit like when it sends a hard drive to sleep). But all such settings that I'm aware of, on the workstation, are disabled precisely because I do not want the workstation sleeping at any time for any reason, as it runs a whole bunch of maintenance tasks (mainly overnight).

So has anyone got any idea what setting might have caused the above behaviour and where I need to go to disable it?
  • On Mon, 08 Oct 2018 14:24:01 GMT, MichaelJacobs
    <MichaelJacobs@no-mx.forums.microfocus.com> wrote:

    >
    >don't know how to describe it any better.
    >
    >I suspect this is a Windows problem not a Novell/OES problem but I'm
    >hoping someone here has seen similar behaviour and knows the simple
    >tweak that will fix it.
    >
    >Here's the symptom that alerted me to the problem.
    >
    >We have two servers running. One is the actual working server. The other
    >is a complete mirror of the first, updated daily with a complete backup
    >of 1 to 2.
    >That system has been working reliably for 5 years.
    >
    >Since I rebuilt my Windows workstation (to version 1803) a couple of
    >weeks ago, which contains and runs the backup software, I've seen this
    >unusual behaviour.
    >
    >After the rebuild, it worked for the first week or so.
    >
    >Came in this morning and noticed that it had failed, with the backup
    >software showing that it had been unable to access the reserve network.
    >
    >Fired up my file browser and I found that I too could not access any of
    >the partitions on the second server.
    >
    >I was about to restart the server but I took a look at it and it looked
    >completely normal and I couldn't see any faults logged.
    >
    >So I went back to my file browser and, instead of trying to read a
    >partition on the second server, I just typed in the root. That came up
    >as normal, showing all the partitions, all of which were now accessible.
    >Problem solved.
    >
    >Except that I have no idea why they became inaccessible in the first
    >place and I'd rather it didn't happen again! It looks like some kind
    >windows timeout (a bit like when it sends a hard drive to sleep). But
    >all such settings that I'm aware of, on the workstation, are disabled
    >precisely because I do not want the workstation sleeping at any time for
    >any reason, as it runs a whole bunch of maintenance tasks (mainly
    >overnight).
    >
    >So has anyone got any idea what setting might have caused the above
    >behaviour and where I need to go to disable it?


    Personally I try to keep workstations out of the loop for something as
    important as backups. I prefer it to be all server based. You never
    know what MS might do that might break your backups. But to answer
    your question...yes this is a Windows issue... We are transitioning
    to Win10 here and so far the best solution I have found for sleep
    issues it to create a custom power plan, make it high performance, and
    verify the desired settings. After setting all that, reboot the PC.
    Not sure why after all this time that a reboot would be necessary, but
    we noticed that the power plan changes don't always seem to take until
    after a reboot. See if that makes a difference.


    --
    Ken
    Knowledge Partner

    Create and vote for enhancements!
    https://www.microfocus.com/products/enhancement-request.html
  • Thanks Ken,
    I'll try the power plan and see if it keeps the net alive tonight. I'll feed back results on Monday
  • The power plan already had everything which could initiate "Sleep" disabled.

    Then had inspiration and added "/persistent :Yes" to my drive mappings

    That seems to have fixed it for 4 of the 5 relevant drives.

    Still working on the 5th!
  • On Mon, 15 Oct 2018 16:14:02 GMT, MichaelJacobs
    <MichaelJacobs@no-mx.forums.microfocus.com> wrote:

    >
    >The power plan already had everything which could initiate "Sleep"
    >disabled.
    >
    >Then had inspiration and added "/persistent :Yes" to my drive mappings
    >
    >That seems to have fixed it for 4 of the 5 relevant drives.
    >
    >Still working on the 5th!


    Are these drives on OES or something else?
    How are you mapping the drives?

    --
    Ken
    Knowledge Partner

    Create and vote for enhancements!
    https://www.microfocus.com/products/enhancement-request.html
  • "How are you mapping the drives?"

    Good question. I found the Novell user scripts stopped working for me a few years back and after failing to fix, I moved to a simple batch file which does the job either on reboot or demand.

    And that's worked perfectly for over 5 years, including permitting these failing backups without losing drive access.

    First, though, let me fess up. My previous post was premature. The problem had NOT been resolved by /persistent :Yes or the powerplan. I allowed myself to be misled by an unrefreshed display of the backup results whch wrongly made me believe that the backups had worked. They hadn't.

    Furthermore, I'm pretty sure it's not a drive mapping issue of any kind (so my previous inspiration was a waste of time) Not least because I don't (and never have) map the drives to the destination. (It's a reserve server. We don't normally need access to it other than for the backups, so why bother mapping?)

    The backup software I'm using (Syncback) identifies network copies quite intelligently and advises substitution of drive letters for full network path mapping. So, for example, my active network drives are S, T, U, V and Y but the backup is not from, say, Y:\ to Z:\, its from
    \\SERVER-2012\DATA\ TO \\SERVER-2013\DATA\

    and Windoze is clearly losing awareness that \\SERVER-2013\ exists.

    How do I know it's that one, and not \\SERVER-2012\ ?

    because I run another backup which copies the contents of that server to my local E drive as well, and that backup continues to behave as normal. Which gives you a clue as to why I'm NOT using Server based backups. I'm copying to multiple targets, some of which are not on the network.

    That said, given that it's ONLY the backup from one server to the other that's failing, I'm open to advice on how to implement a Server based backup for that element at least. But I've never actually done that so I'd be grateful if you could point me to the idiot guide on how to do that.
  • On Fri, 19 Oct 2018 13:14:02 GMT, MichaelJacobs
    <MichaelJacobs@no-mx.forums.microfocus.com> wrote:

    >
    >"How are you mapping the drives?"
    >
    >Good question. I found the Novell user scripts stopped working for me a
    >few years back and after failing to fix, I moved to a simple batch file
    >which does the job either on reboot or demand.
    >
    >And that's worked perfectly for over 5 years, including permitting these
    >failing backups without losing drive access.
    >
    >First, though, let me fess up. My previous post was premature. The
    >problem had NOT been resolved by /persistent :Yes or the powerplan. I
    >allowed myself to be misled by an unrefreshed display of the backup
    >results whch wrongly made me believe that the backups had worked. They
    >hadn't.
    >
    >Furthermore, I'm pretty sure it's not a drive mapping issue of any kind
    >(so my previous inspiration was a waste of time) Not least because I
    >don't (and never have) map the drives to the destination. (It's a
    >reserve server. We don't normally need access to it other than for the
    >backups, so why bother mapping?)
    >
    >The backup software I'm using (Syncback) identifies network copies quite
    >intelligently and advises substitution of drive letters for full network
    >path mapping. So, for example, my active network drives are S, T, U, V
    >and Y but the backup is not from, say, Y:\ to Z:\, its from
    >\\SERVER-2012\DATA\ TO \\SERVER-2013\DATA\
    >
    >and Windoze is clearly losing awareness that \\SERVER-2013\ exists.
    >
    >How do I know it's that one, and not \\SERVER-2012\ ?
    >
    >because I run another backup which copies the contents of that server to
    >my local E drive as well, and that backup continues to behave as normal.
    >Which gives you a clue as to why I'm NOT using Server based backups. I'm
    >copying to multiple targets, some of which are not on the network.
    >
    >That said, given that it's ONLY the backup from one server to the other
    >that's failing, I'm open to advice on how to implement a Server based
    >backup for that element at least. But I've never actually done that so
    >I'd be grateful if you could point me to the idiot guide on how to do
    >that.


    This is all a bit confusing because I don't know your layout. What OS
    and versions are your servers running? If OES, are you using the OES
    Client on your Windows PCs? Please explain what you are working with
    there.

    --
    Ken
    Knowledge Partner

    Create and vote for enhancements!
    https://www.microfocus.com/products/enhancement-request.html
  • >>This is all a bit confusing
    Tell me about it!

    To be fair, I think I'm posing this question in the wrong place. This is nothing to do with the Client. The Client is running splendidly. This is a pure Windows 1803 problem (I've been running with the current net config for the last 3 years on 1511 without this problem - it's only bitten since I updated). I've been looking for others with networking issues following their own updates to 1803 and there are thousands. It may or may not be possible to address the issue with a tweak to Client settings, but it's not reasonable for me to ask you to sort a problem caused by Microsoft.

    The only thing I will consider, though, is using whatever tools you recommend for "Server to Server" backup as touched on above. That won't actually resolve all my problems because - contrary to what I wrote in my previous - some of my local backups ARE also failing (I'd been misreading the display).

    The Novell Version running on both servers is Netware 6.5 The client is Client for Open Enterprise Server 2 SP4 (IR7a)
  • On Mon, 22 Oct 2018 13:14:01 GMT, MichaelJacobs
    <MichaelJacobs@no-mx.forums.microfocus.com> wrote:

    >
    >>>This is all a bit confusing

    >Tell me about it!
    >
    >To be fair, I think I'm posing this question in the wrong place. This is
    >nothing to do with the Client. The Client is running splendidly. This is
    >a pure Windows 1803 problem (I've been running with the current net
    >config for the last 3 years on 1511 without this problem - it's only
    >bitten since I updated). I've been looking for others with networking
    >issues following their own updates to 1803 and there are thousands. It
    >may or may not be possible to address the issue with a tweak to Client
    >settings, but it's not reasonable for me to ask you to sort a problem
    >caused by Microsoft.
    >
    >The only thing I will consider, though, is using whatever tools you
    >recommend for "Server to Server" backup as touched on above. That won't
    >actually resolve all my problems because - contrary to what I wrote in
    >my previous - some of my local backups ARE also failing (I'd been
    >misreading the display).
    >
    >The Novell Version running on both servers is Netware 6.5 The client is
    >Client for Open Enterprise Server 2 SP4 (IR7a)


    I'm not sure what to suggest at this point...
    You're running the OES client and you have old Netware servers, but
    you use the Microsoft map command? I don't understand that. This
    really is not an OES client issue.

    Regarding server to server backup...I assumed you were on a current
    operating system. With OES or Windows, you can easily script
    things... crontab and rsync on OES or scheduled tasks on Windows. Not
    sure if there is anything still available for Netware. I really liked
    Netware, but I haven't used it in so long that I'm getting a bit rusty
    on it. And it hasn't been supported in ages. There used to be a very
    cool program called TaskMaster that ran on Netware and provided lots
    of capabilities. It was from Avanti Technology. Not sure if you can
    even get that anymore.

    Quite honestly, I would suggest you get someone in to look at your
    environment and see what it would take to bring things up to date and
    make them work the way you want.

    --
    Ken
    Knowledge Partner

    Create and vote for enhancements!
    https://www.microfocus.com/products/enhancement-request.html
  • Solution:

    Put the network credentials in the (syncback) task definition.

    Never been necessary before but looks like the latest version of Windoze has decided to expire network credentials after some unspecified and undocumented timeout. This would be acceptable if it was their own network, but ours isn't.
    Wish we could sue the *******s for the several hours this has cost me!


    Anyway, sorted. Thanks for listening!
  • On Tue, 30 Oct 2018 14:44:01 GMT, MichaelJacobs
    <MichaelJacobs@no-mx.forums.microfocus.com> wrote:

    >
    >Solution:
    >
    >Put the network credentials in the (syncback) task definition.
    >
    >Never been necessary before but looks like the latest version of Windoze
    >has decided to expire network credentials after some unspecified and
    >undocumented timeout. This would be acceptable if it was their own
    >network, but ours isn't.
    >Wish we could sue the *******s for the several hours this has cost me!
    >
    >
    >Anyway, sorted. Thanks for listening!


    Glad you have it working now!

    --
    Ken
    Knowledge Partner

    Create and vote for enhancements!
    https://www.microfocus.com/products/enhancement-request.html