T
TSoward
I'm trying to understand what is happening at one of my clients. Though they have a server , they also have, for historical and procedural reasons, a virtualized Windows XP machine where there is a share to which every user has a drive letter mapped (call it B
where they save backup copies of certain files. Primary storage is on the domain server.
The actual users are all on Windows 10 (or 7), the XP machine is [almost] only accessed as a share, no user runs it at its console (it is normally logged off). In general all users are logged on 8-10 hours per day.
There are about 15 users, but for 11 months of the year activity is such that there is limited use of the B: mapping. When needed, users click on it and save files into the effective folder. Even though there are more than 10 users in total, seldom would more than 1 access the share at a time, and certainly not 10, but even though, over time, more than 10 different users establish sessions, they never get refused, leading me to believe that somehow sessions end, I would have thought that this would be when 0 files are open in the session, the session has been in existence longer than the other sessions with 0 files open, and another user came knocking wanting to have access - but that may be wrong based on what I am seeing:
For a 1 months per year, this mapping is more active. It appears that at times there are at least 9 sessions (maybe 10?), though only 1 or 2 typically have open files. At this time the following are observed:
SO, my questions are:
I understand that we could correct this by replacing the virtual XP with a server (or maybe WIndows 10?) but for now a workaround would be a better.
Continue reading...
where they save backup copies of certain files. Primary storage is on the domain server. The actual users are all on Windows 10 (or 7), the XP machine is [almost] only accessed as a share, no user runs it at its console (it is normally logged off). In general all users are logged on 8-10 hours per day.
There are about 15 users, but for 11 months of the year activity is such that there is limited use of the B: mapping. When needed, users click on it and save files into the effective folder. Even though there are more than 10 users in total, seldom would more than 1 access the share at a time, and certainly not 10, but even though, over time, more than 10 different users establish sessions, they never get refused, leading me to believe that somehow sessions end, I would have thought that this would be when 0 files are open in the session, the session has been in existence longer than the other sessions with 0 files open, and another user came knocking wanting to have access - but that may be wrong based on what I am seeing:
For a 1 months per year, this mapping is more active. It appears that at times there are at least 9 sessions (maybe 10?), though only 1 or 2 typically have open files. At this time the following are observed:
- Some users drive mapping to B: disappear. Though the mapping are all set up by the server using Group Policy, and at logon B: its present (though unused) the user finds that the mapping disappears, but only in this interval where more people are using that drive letter. They sometimes can manually re-map the drive, other times not. Other users never have their drive mapping disappear. (I should have been more precise, each user has their own PC, its certain PCs that have B: mapping disappear in this situation)
- Sometimes users cannot save to the B: drive, Windows having exceeded the 10 session limit. However, even when this is the case, some of sessions have 0 open files so presumably could be available to be displaced.
SO, my questions are:
- What explains the disappearing drive mapping? Is there something to be done to make it not disappear?
- What are the circumstances that cause a Session with zero files open to end, allowing someone else to start a Session? I know I can force it, but what causes them to end on their own?
- How does this self correct 11 months of the year but not when activity is more concentrated? (might be the same answer as 2)
I understand that we could correct this by replacing the virtual XP with a server (or maybe WIndows 10?) but for now a workaround would be a better.
Continue reading...