The Day the Access Rights Lists Stood Still
What should have been a standard Banyan StreetTalk
for Windows NT administrative chore turned into a major
source of Sunday afternoon stress.
If you do technical support for a living and are part
of an on-call rotation, you know how it feels. You make
plans for a special evening, yet you wear that pager with
some anxiety and an uneasy feeling in your stomach. You
know that if the beeper sounds, all bets are off. Plans
go awry. This story is about a time my beeper went off.
Mixing It Up with StreetTalk
StreetTalk for Windows NT
|To learn more about StreetTalk
for Windows NT, visit the Banyan Web site
The technical issue at hand revolves around a product
from Banyan Systems, Inc. called StreetTalk for Windows
NT. StreetTalk for NT runs on an NT 4.0 server and lets
you integrate NTincluding access to NT printers
and file sharesinto your existing Banyan VINES network.
StreetTalk for NT can also assist in migration away from
Classic Banyan VINES servers to NT. A planned migration
isnt required for Banyan clients to access the NT
resources either. Banyan users can be easily migrated,
if desired, to the StreetTalk for NT server.
In addition, file volumes, printers, users, and other
resources on a StreetTalk for NT server can be administered
via a simple Banyan administrative tool called StreetTalk
Explorer. I find this utility intuitive and easier to
use than the NT administrative tools. This ease of management
is a large lure and one of the real values in using StreetTalk
for NT rather than NT exclusively.
A Banyan file service is created via StreetTalk Explorer
and points to an NT file volume. The data contained in
the volume resides on an NT server, and Banyan users can
access it via the Banyan file service. Banyan services
can be stopped or started via an NT Banyan File
Services option shown with the other NT services
in the Services Control Panel.
The level of access that a Banyan user has to data on
a Banyan file service is determined from an Access Rights
List (ARL). ARLs are managed via the StreetTalk Explorer
tool. Each file and directory on a Banyan file service
has its own ARL. Without this ARL, users cant access
At the time of this writing, there are two releases of
StreetTalk for NT available: version 7.5 and the new 8.5.
My customer is using 7.5. (He wasnt ready to consider
8.5 until we completed further stress testing.)
The person paging me on Sunday had a Monday 8 a.m. deadline
to create a Banyan file service on his StreetTalk server.
Come Monday morning, hundreds of Banyan users would be
trying to access the data residing on the NT file volume
that the Banyan file service would point to. The ARLs
would have to be properly configured to ensure this access.
He had started the project on Sunday around noon. Normally
this would be simple, but since this was my on-call weekend,
who could tell what would happen?
The Access Rights Lists were malfunctioning for this
newly created Banyan File service. Test Banyan users who
should have been able to access the new service on the
StreetTalk for NT server couldnt. Other pre-existing
Banyan file services on the same StreetTalk for NT server
were fully accessible to Banyan users. When the users
tried to access the new Banyan file service, they received
an Access Denied error. My online documentation
didnt show this as a known issue either. The clock
The Hunt for a Solution
We started with simple, methodical troubleshooting techniques
for an access rights issue. I had the customer download
the latest version of StreetTalk Explorer from the Banyan
Web site. Setting ARLs using the new utility didnt
resolve our problem. We even tried using the DOS SETARL
utility to set ARLs instead of using the GUI administrative
tool. This also didnt work. In the back of my mind
I knew that this customer wasnt at the latest StreetTalk
for NT patch level (they had patch NT98029, and the latest
patch available was NT98048.) They wanted to avoid applying
the most recent patch if possible.
I had the customer create a new NT file volume. Then
I had him create a new Banyan file service, point it to
the new NT file volume, and configure the ARLs as desired.
If the users could access the new Banyan file service,
then we could copy the data from the old NT file volume
to the new one. But this didnt work either.
At this point I gave in and placed a call to Banyan for
weekend tech support. Banyan promptly got back to me and
advised checking NT file volumes for sharing. The NT file
volumes shouldnt be shared since StreetTalk handles
the sharing. In fact, NT volume sharing can interfere
with ARLs. Our volumes were shared. This could be the
cause of our problem! Alas, setting them to unshared didnt
There are two files in the Program Files | Banyan | Files
| Data folder, which maintain the ARL settings for all
of the Banyan File services that reside on the StreetTalk
for NT server. Banyan suggested that these two files might
be damaged. The technical support folks recommended we
stop the Banyan File Service NT service. Then
we were to move these two files to another location and
restart the Banyan File Service NT service.
The two ARL files should be automatically re-created.
The large drawback here is that ARL settings for all
files and directories for every Banyan file service on
the server are returned to default settings. The ARLs
would have to be manually re-created for all Banyan file
services, not just for the one file service that was causing
the problems. Ouch! This customer had about 10 Banyan
file services on the StreetTalk for NT server, so we knew
it would have a fairly large impact.
We performed the steps and moved those two ARL files
to another location. Then we restarted the service, thus
re-creating the ARL files. We reconfigured and saved the
ARLs on the Banyan file services using StreetTalk Explorer,
giving users the needed access to the data on the NT file
volumes. However, they still received access denied
messages when trying to access the data. And now, none
of the Banyan file services were accessible to Banyan
users. Users received the access denied error when trying
to access data on all Banyan file services. The issue
had just increased in priority by a factor of 100. I began
to realize that I probably wouldnt be making my
Sunday dinner engagement.
So what else did I have to fall back on? Thats
rightthe patch! We had already spent a good chunk
of time on this problem. We decided that since our conventional
attacks were coming up short, we needed to apply the latest
StreetTalk for NT patch so that we were at the latest
code revision. There were also specific fixes in regards
to the ARL functionality in this patch. Without further
delay we applied the patch.
This is what nightmares are made of. The patch resolved
nothing in regards to our problem.
The Final Solution
Out of pure desperation, the customer and I began some
tests. We knew what we couldnt do. It was time to
identify what we could do. Our hope was that maybe if
we tried a few small changes we could make some progress.
We specifically looked at where we were pointing the Banyan
file service to in the NT directory structure, as well
as where the virtual root was for the drives
being mapped via user profile. And then the two workarounds
made themselves apparent.
Workaround 1: Configure the Banyan
users to map a drive to a subdirectory of the Banyan File
service, rather than the root.
Banyan users can map a drive letter to the Banyan file
service via a SETDRIVE command, usually located in the
users Banyan user profile. You can use a /ROOT switch
on the setdrive command to specify a subdirectory path
of the file volume. To the user this subdirectory path
will appear as the root of the drive. When
we configured the /ROOT switch to a subdirectory of the
Banyan file service, suddenly users could access the data.
Although the Banyan ARLs were configured to allow users
to access the root of the file volume, they still couldnt.
We were quite happy that subdirectories didnt have
Workaround 2: Configure the Banyan
file service to point to a subdirectory of the NT file
volume, rather than the root of the NT file volume.
You configure a Banyan file service via browsing to point
to an NT file volume. You can pick the root of the NT
file volume, or any subdirectory of the NT file volume,
to appear to be the root of the Banyan file service. This
site was configuring the Banyan file service to point
to the root of the NT file volume. When we configured
the Banyan file service to point to a subdirectory of
the NT file volume, all ARLs worked, and Banyan users
could access the data on the Banyan file services residing
on the StreetTalk for NT server. Just dont keep
data that users need to access in the root of the NT file
The user chose workaround 1 and with a simple addition
of a /ROOT:[directory path] parameter appended to the
Banyan SETDRIVE commands in the users profiles,
all data was again accessible. The user was able to add
the new Banyan file service and meet his goal by 6:30
Sunday eveningand I made my dinner!
In addition, later on during regular business hours,
Banyan reproduced this problem in StreetTalk for NT 7.5.
While they were at it, Banyan also confirmed that the
bug doesnt exist in 8.5. At present the client doesnt
intend to upgrade.
So what did we learn from this? Should we always keep
software at the latest revision? We all know that sometimes
being on the bleeding edge of technology is bad, and I
have many scars to prove it, so thats not the lesson
here. Should we always keep a rubber chicken handy for
these types of situations? Yes, definitely. But I also
have two other lessons in mind.
Start earlier. How could this customer have
met the same deadline with less stress and frustration?
If the customer had started earlier than Sunday, which
was less than 24 hours before the deadline, we would
have encountered the problem earlier and had less
of a deadline over our heads.
Do administrative tasks during business hours.
Creating an additional Banyan file service and configuring
its ARLs is a simple administrative task. This could
have been done during business hours with no impact
to the production network. ARLs could have been configured
to allow a non-administrator test user to access the
data. Once the test user could access the data, we
could expect any of the production users to be able
to access the data as well.
The benefit of having the failure during business hours
is the wealth of resources available, which just isnt
there on the weekend. For example, the Banyan engineer,
while very knowledgeable, didnt have his extensive
workplace lab available to reproduce our problem until
Monday, after the deadline. I didnt have the resources
of my workplace lab to test this on. Had this failure
occurred during the previous week, we could have attained
a better understanding of the problem faster. We could
have reproduced the failure, advised the upgrade to StreetTalk
for NT 8.5, or used the workarounds, and let the customer
make the decision. That way, the process might have occurred
in a timely fashion and without much agony.