silver@xrtll.uucp (Hi Ho Silver) (01/08/91)
In the past few days, I've been involved in upgrading an Advanced 286 V2.15 server to 386 V3.1, and I've run into a couple of odd problems. I'd appreciate any input on whether I did anything wrong, or if these are just bugs in Novell, especially since I'll be doing the same thing several times for other clients. - When using the upgrade utility that ships with 386 to transfer the bindery, I was unable to transfer passwords or trustee rights. Users and groups were created, but I had to manually go through and set up the rights for every user and group. - The system does not seem to read the system name and network number from the AUTOEXEC.NCF file; instead, it sits patiently waiting for me to key them in when it's booted. - For a while, we had the two servers running simultaneously (but with different names, of course). When the NW286 server was the default server, a login to the NW386 server would fail to execute the login script. - In NW286 (Adv and SFT) and in 386, the documentation lists a default system login script, which it claims is executed if you don't have one set up. In actual fact, it gets executed after the system login script. Is there any way to disable the default one? - The client's LAN had previously sustained much damage when a supervisor- equivalent employee was fired. Due to this, the client insists on having two people who each know one half of the supervisor password, and having all accounts which were previously supervisor-equivalent made into workgroup/user account managers. So far, so good. But the only effective way I've found of doing this is to have all of the following conditions met: -group EVERYONE is managed by a new group, SUPERS -group SUPERS manages EVERYONE -group SUPERS is managed by each of the individuals in it -group SUPERS manages every individual user (except SUPERVISOR) -group SUPERS is set up as a managed under SYSCON's Supervisor Options menu If I have SUPERS managing the group EVERYONE, rather than its users, it is useless. If I don't say SUPERS is managed by each of the individuals in it, its powers don't seem to accrue to its members. This is a potential pain in the neck, especially since sooner or later, someone will add a new user and forget to add them to the list of users managed by SUPERS. If I had a whole day to do nothing but play with this, I'd perhaps be able to figure something better out, if there is something better, but I don't have the time. Can anyone suggest a better way? As mentioned above, the old system of supervisor-equivalent accounts is not acceptable to our client. I'd prefer email replies and am willing to post a summary of responses. -- __ __ _ | ...!nexus.yorku.edu!xrtll!silver | always (__ | | | | |_ |_) >----------------------------------< searching __) | |_ \/ |__ | \ | if you don't like my posts, type | for _____________________/ find / -print|xargs cat|compress | SNTF