May/Jun 2003 by Novell Technical Services
Tips and Tricks
Problem: Trustee assignments don't work after upgrading from NetWare 4.x to NetWare 6. When viewing the Trustees of the file or subdirectory, the user is listed. However, when you check "Rights to Files and Folders," the user does not have rights. Deleting the trustee and adding it back alleviates the problem but it occasionally returns.
Solution: The following are descriptions of similar Global Unique Identifier (GUID) issues that have been known to prevent trustee rights from appearing correctly on NSS volumes after upgrading from NetWare 4.x to NetWare 6.
You may experience the problem if eDirectory is not installed in the replica ring that contains the user object that has a trustee assignment to the server being upgraded. You may also experience the problem if the server being upgraded doesn't have a real copy of the user object that holds a trustee assignment to it.
This primarily refers to any version of NDS 6.x running on Netware 4.x. All other versions support GUIDs. However, the enforcement of adding GUIDs to objects was added in eDirectory 8.5.
Problem: NDS 6.x does not understand GUIDs. So if a real copy of the user object doesn't exist on a server running NDS 7.x or higher, the GUIDs won't be created. Therefore, nothing will be written to the NSS file system. If the GUID is not present, NSS obviously won't see any GUID attribute in NDS when it attempts to write a GUID into its metadata for the trustees and thus won't give any trustees for the user to the NSS volume.
How to avoid the problem: At least one server must be running NDS 7.x or higher in every replica ring in which users have been assigned file system trustee assignments.
Another workaround is to ensure that the server being upgraded contains all replicas for all users that have file system trustee assignments to that server before upgrading it.
The Netware 4.x server is not running an NDS version that will consistently synchronize with servers that are running eDirectory 8.6.x or higher (i.e., any Netware 6 server).
Problem: The GUIDs that are created on the user objects are not being synchronized to the Netware 4.x box (along with other attributes). When the Netware 4.x box is upgraded, there is not a GUID so the eDirectory upgrade adds a GUID to the object. Now the same object is on two different servers with two different GUIDs. The NSS file system will only read one of the GUIDs. This will cause complete loss or inconsistent results of trustee assignments.
How to avoid the problem: Make sure that all Netware 4.x servers are running NDS version 6.17 or higher before upgrading any server to Netware 6.
Random information on an object may not synchronize to all servers in the replica rings when using the FCS version of eDirectory 8.6.2. This issue can be verified by examining the modification timestamp (MTS) of the GUID attribute on the user that lost trustee rights for each replica. The MTS should be identical to the GUID value. If the MTS is older than the transitive vector for that partition, then random information on the object probably didn't synchronize to all servers in the replica ring.
Note: For more information on how to Use NDS iMonitor to look at these attributes, refer to the eDirectory 8.7 documentation at: http://www.novell.com/documentation/lg/ndsedir86/index.html under the Novell eDirectory Management Utilities | Novell iMonitor section.
Problem: eDirectory 8.6.2 SP2 or higher is required on all servers running eDirectory 8.6.2. There were some issues in which the transitive vectors advanced too soon and not all data was synchronized between replicas.
How to avoid the problem:
- Make sure that eDirectory 8.6.2 SP2 or higher is applied to all servers running eDirectory 8.6.2 before upgrading servers to Netware 6.
- If performing an across-the-wire migration, make sure that to apply the eDirectory 8.6.2 SP2 patch or higher to the temporary server before migrating to Netware 6.
Upgrade a server to Netware 6 before the GUID attribute is synchronized to all servers in the replica ring(s) that contain the user objects.
Problem: When another Netware 4.x box is upgraded that is in the same replica ring as the original box in the above scenario, there is not a GUID attribute on the user. So the eDirectory upgrade adds a GUID to the object. Now you have the same object on two different servers with two different GUIDs. The NSS file system will only read one of these GUIDs. This will cause complete loss or inconsistent results of trustee assignments.
The NSS volume will only write the GUID to its metadata the first time, and does not sync its information again. DMPTRUST.NLM is a utility that will check the NSS GUIDs with the NDS GUIDs and report any errors.
How to avoid the problem: Make sure you give the replicas time to synchronize. Also follow the instructions from How to avoid the problem from Scenario 3.
Solution: How do I fix the problem if one of the above scenarios has occurred?
Note: The following should be executed on the Netware 6 server that was just upgraded.
- Make sure you are on the latest version of NSS code.
- Do "NSS /resetidcache" from the server console. This will reset the NSS cache with the current eDirectory information.
- The NSS cache is refreshed by default every 25 hours. Failure to reset the cache could give you incorrect information when using DMPTRUST.NLM and SYNCGUID.NLM.
- Use DMPTRUST.NLM first to make sure that inconsistencies exist. Refer to the readme.txt in DMPTRUST.EXE for instructions on using DMPTRUST.NLM.
- Make sure that NDS has synchronized the same GUID attribute on all users that have trustee assignments to the upgraded server throughout the corresponding replica ring.
- If scenario 3 occurs, the only way to synchronize the GUIDs is to perform a partition epoch. (Note: For more information on declaring a partition epoch, see http://support.novell.com/cgi-bin/search/searchtid.cgi?/10073685.htm)
- Do not forget external references. After the real copy of the objects have the correct GUID, run a backlinker process to update the external references with the new GUID.
- Running the backlinker process
- Set dstrace=on
- Set dstrace=+blink
- Set dstrace=*b
- Go to the Directory Services screen and make sure the backlinker process finishes successfully.
- Contact Novell Technical Support to get a utility named SYNCGUID.NLM to synchronize the GUIDs between NDS and NSS. Refer to the readme.txt in SYNCGUID.EXE for instructions on using SYNCGUID.NLM. (Make sure to reset the NSS cache before running SYNCGUID.NLM. This is done by running "nss /resetidcache" from the server console. Failure to reset the cache will allow SYNCGUID.NLM to use cached information rather than the newly synchronized eDirectory information).
Do "NSS /VisibilityRebuild=VolName" to reset the NSS visibility list.
When upgrading a GroupWise post office or domain to GroupWise version 6.0 or 6.5 and they are both on the same server, the post office version does not get updated when the new agents are loaded.
Problem: The *.DC files did not update correctly. The GWPO.DC file is not in the post office directory or is an older version of the file. The POA checked the wphost.db on for the owning domain's version, since the MTA is in the process of updating the domain, the post office still shows the domain as the older version. By the time the domain completes its upgrade and sends the admin messages to update the post office, the POA has skipped the upgrade process.
Solution: Following are some steps to take to update the database. They should be done in the order listed.
- Check the database version from ConsoleOne.
- If the version is 6.5, then exit the POA and restart it
If the post office was created with GroupWise 4.x, it's possible that the old security settings have caused the POA to correct those settings. Restarting the POA will complete the update allowing users to access the post office with the GW 6.5 client.
Prior to the POA exit and restart, the GW 6.5 client will get an error telling the user that the client version is too new for the post office version.
- If the database version is still 5.5 then check the dictionary files in the root directory of the post office. They should have the
- Gwpo.dc (8/13/2002)
- ngwguard.dc (1/9/2003)
If the dates are not correct, copy the files from the Admin CD from the following locations:
- gwpo.dc: <cd root directory>\domain directory
- ngwguard.dc: <cd root directory>\po directory
- Check the POA console screen. F10 | Admin Status | Recovery Count
If the Recovery Count is 0 (zero) then the POA didn't pick up the needed trigger to update the database.
To correct this and complete the update, select the "Perform DB Recovery Now?" option on the same POA console screen from which you checked the Recovery Count.
Allow the recovery to complete and then check the post office version in ConsoleOne. It should now be 6.5.
Prevention: To prevent this from happening, only load the MTA and let it complete the update to the domain. Once it is complete, load the POA for the post office on the same server as the domain.
Start taking advantage of all the hidden capability of your Novell products. Join the popular Novell Cool Communities, the fourth most heavily visited content set at Novell. Get fresh tips and tricks every week that will keep you ahead of the game, and make you a hero to your boss and your end users. Or try one of the 650 + Free (or almost free) Tools in our storehouse.
If you're already a power user, consider sharing the insights you've gained through years of experience. Once you start seeing the feedback from your grateful readers you'll be hooked on sharing your tips. You can even find a home for your homegrown utilities by sharing them on the Free Tools pages. To you, it's just that script you wrote to speed up the install. To someone else, it means not having to work over the weekend.
Come see for yourself. It's fun, it's free, and we'd love to have you.
Keep administrators from being locked out of machines
ZENworks cool solutions article
by Leonard Zebrowski
Here's a tip recently posted on Cool Solutions that has already collected an impressive number of five-star ratings. Get tons more like this at www.novell.com/coolsolutions.
We had a problem with multiple machine images with different and sometimes forgotten local administrator account passwords. Also, some of our users with local admin rights occasionally change the password to Administrator or backdoor accounts, locking us out of the machines.
I wrote a simple ZEN Script to install a service on all machines that every time a machine is rebooted the chosen accounts' passwords are reset. When necessary, I can change the passwords by pushing down a new file. This is how I did it:
Note: All the files used in this solution are available in the zip file referenced in the URL below.
I wrote a batch file called reset.bat with the following commands:
- Net use administrator <password>
- Net use <backdoor> <password>
- Net use <backdoor1> <password>
I used a Bat2Exec program to convert reset.bat to reset.com to encrypt the file for security.
I wrote a simple ZEN package to:
- Copy reset.com to C:\Winnt\System32
- Copy srvany.exe to C:\Winnt\System32 (from NT Resource kit)
- Install the appropriate registry keys
Every time the machine reboots all passwords included within reset.com are standardized. Anytime I need to change the passwords I rewrite reset.com and push the new file out using ZEN. This works on both NT 4 and Windows 2000 machines.
I've shared everything I use in this zip file, with the exception of the "real" reset.bat/com file. The included file will reset only the administrator password to "password."
Download the zip file from http://www.novell.com/coolsolutions/zenworks/features/trenches/tr_reset_passwords_zw.html.