Another Pathworks Problem

[John Harper (Barbour)]

Hello everyone,

I have a Pathworks problem, and have reviewed all the entries in this forum which are similar. This has got me so far along towards a fix, but I can’t get the last bit to work.

We have made some infrastructure changes which required that Pathworks was changed.

We originally had :

In the UK a domain, BARBOURS with 2 Windows 2003 domain controllers and a three node Alpha cluster as a member server running Pathworks 7.3B

In the USA a domain MILFORD with no windows servers and an alpha server (NICKEL) as a PDC, also Pathworks 7.3B

We are changing to a single domain, BARBOURS with 2 Windows 2003 domain controllers in the UK and a single Windows 2003 domain controller in the USA. The UK cluster is still a member server. No problems so far.

I re-configured Pathworks in the USA to join the BARBOURS domain. Initially it failed, but looking at previous posts I found a reason (WINS not configured).

I have now been able to join the domain, entering he name of the PDC emulator when asked. This worked and the Alpha server can be seen in the active directory of servers in both UK and USA.

Pathworks was restarted and Admin runs. A command SHOW ADMIN takes about 30 seconds to respond, and shows the following :

Administration information:

The domain being administered is: BARBOURS
The domain controller for the domain is:(unknown)
The domain controller type is: (unknown)

The server being administered is: NICKEL
The server type is: Advanced Server for OpenVMS

The user name is: ADMINISTRATOR
The user is logged on to domain BARBOURS and has been authenticated.
The user's privilege level on this domain is: ADMIN
The user's operator privileges are: PRINT COMM SERVER ACCOUNTS
The user's workstation is NICKEL and is in domain BARBOURS.

It is possible to log on with ADMIN, and the logon is processed by the windows server in the USA

BARBOURS\\NICKEL> logon
Username: administrator
Password:
The server \\INCFSERV01 successfully logged you on as Administrator.
Your privilege level on domain BARBOURS is ADMIN.
The last time you logged on was 11/20/08 06:39 AM.

I can create a share, but when I try to set permissions I get this :

BARBOURS\\NICKEL> mod share public/perm=("domain users"=full)
%PWRK-E-DCNOTFND, cannot find Primary Domain Controller for "BARBOURS"

And SHOW USERS in ADMIN also waits about 30 seconds before returning :

%PWRK-E-DCNOTFND, cannot find Primary Domain Controller for "BARBOURS"

I have looked at the error log using SHOW EVENT/SINCE/FULL and I’m seeing this :

E 11/20/08 06:35:05 AM NETLOGON None 3210 N/A NICKEL
Failed to authenticate with INCFSERV01, a domain controller for domain BARBOURS.

Clearly the servers can see one another as I was able to join the domain, and commands like NBSHOW KNBSTATUS successfully find all the domain controllers.

I seems as though I tell the Pathworks server the name of its domain controller, but this should happen automatically.

Any help would be gratefully received.

[John Gillings]

Pathworks and Windows 2003? I'd be very surprised if you get this to work.

Pathworks was replaced by Advanced Server about a decade ago. Since the Windows folk, in their wisdom, keep making incompatible changes to the protocols, it's become more or less impossible to maintain the products so they interoperate correctly with recent versions of windows. Advanced Server has been replaced by a port of the open source CIFS.

[Brad McCusker]

John Gillings - He's saying PATHWORKS 7.3B but there never was any such product. I'm sure he means Advanced Server 7.3B. Should work.

I'm still mulling over what's been posted - but don't worry about the version.

[Karl Rohwedder]

John,

we had same problem a while ago (with W2000 as PDC), which occurred after some structural changes on the windows side.
At least got it fixed by entering the DC's into LMHOSTS and by setting the same WINS server on the VMS side as has been set on the Windows side.
I attached out LMSHOST as sample.

Btw: the current version is V7.3B with patchset 13

regards Kalle

[John Harper (Barbour)]

Many thanks for the replies. and sorry about the confusion. Over the years we've sort of got into a habit of using words like pathworks and advanced server interchangeably to mean the same thing.

Kalle, I tried defining entries in the LMHOSTS file and while the problem with not seeing the domain controller has not gone away, the users can map to a share so we're working again. So we've got what we want and now it's just a matter of pride and curiosity to nail the underlying problem !!

Thanks again,

John

[Paul Nunez · Accepted solution]

John/Kalle,

The lmhosts file entries provided by Kalle aren't really typical :O)

For example, only one computer in the domain will register/own the name " \0x1b" - the PDC (emulator).

In Kalle's case, since only the first \0x1b entry has the #PRE directive, it's the only one that ever gets loaded into the TCP/IP NetBIOS name cache (so hopefully, that system is indeed the PDC emulator ;o).

Entries without the #PRE directive are only processed when server is attempting to resolve a name and can't find a translation in the cache, from WINS (if enabled), from DNS (if enabled), nor from a broadcast on the local subnet - as a last resort the server scans lmhosts for the name. In Kalle's case, the \0x1b entry with the #PRE will alwasy be present in cache so the other \0x1b entry is never used.

Doing a bit of testing, if you did have #PRE on multiple 0x1b entries, they all would end up in cache; in that case, I'm not sure how Advanced Server will behave.

You can view the cache with:

$ nbshow knbcache

and clear/relaod it with:

$ nbshow knbcache reload

Also, it seems the first #DOM: directive results in the expected cache entry for the name \0x1c, but subsequent entries with #DOM: do NOT create additional \0x1c cache entries. However, if you explicitly include " \0x1c" entries in lmhosts, it DOES add those additional \0x1c entries to the cache.

HTH,

Paul

[John Harper (Barbour)]

Paul,

Thanks for the tutorial on LMHOSTS. I hadn't realised just how complicated it was. Now that I have added an entry with

172.20.1.17 "BARBOURS \0x1B" #PRE

everything is working perfectly.