pathworks BDC lost connection to PDC

[Pieter 't Hart]

As stated in the subject our pathworks BDC lost connection to it's PDC so updates to accounts/groups are not replicated.

Trigger probbably is that the PDC was moved to another IP-subnet about two moths ago but only recently this problem was detected.
routing is OK (ping/telnet)

Versioninfo :
$ ucx sho ver
DIGITAL TCP/IP Services for OpenVMS VAX Version V4.2
on a VAX 4000-705A running OpenVMS V6.2
Pathworks V5 (V5.0-610F)

Pathworks is configured for all protocols(DECNet NETBEUI, TCP/IP) on both machines

Offcourse at TCP/IP-level the hosts are connectable (ping/telnet)
So problems with subnetting/routing are not very likely.

I'm looking for hints to solve this.
Maybe the PDC tries to connect by DECNet instead of TCP/IP. How can i check this?

greetings
Pieter 't Hart

[Antoniov.]

Hello Pieter,
if you talk about PDC and BDC means (I think) the lan manager PDC/BDC (winNT server) and then pathwork; for this environment, TCP/IP is irrilevant (it used only to required license).
All info are accried by NetBEUI/NDIS protocol so you hhave focus on this protocol.
I think you have upgrade pathwork V5.0 with V6.0 (without advanced server still work on Openvms V6.2); with V6.0 my customer works fine using two alpha 400 (very old but still working).
Again, you can reinstall software on BDC and during install start aquiring of data from PDC.
At least, problem mey be simply in Administrator password change lost by BDC so now BDC can't access to database.

H.T.H.
Antoniov

[Edwin Gersbach_2]

Pieter

Well, V5 is a while back and memory is no longer what it used to be :-)

As you moved the PDC, the first thing to check/update is the entry in the PWRK$LANMAN:LMHOSTS. file. Other than that, I have added my hints collection from that ancient times. Hope it helps.

Edwin

[Pieter 't Hart]

Edwin, Antoniov, thanks for your responses

i thing Edwin's suggestion looks the most promising.
some extract from the "hints"

>>> If using TCPIP protocol with PDC
>>> and BDC in different IP Subnets check
>>> the server entries in the
>>> PWRK$LMROOT:[LANMAN]LMHOSTS.; file

there is NO LMHOST file present
>>> NARCIS_$ dir PWRK$LANMAN:LMHOSTS
>>> %DIRECT-W-NOFILES, no files found

I'll create one and test

Pieter

[Brad McCusker]

Pieter,

You write:
++++++++
Offcourse at TCP/IP-level the hosts are connectable (ping/telnet)
So problems with subnetting/routing are not very likely.
++++++++

That depends on how you did the test. If you pinged/telneted an address (xx.xx.xx.xx), then all you have proved is that there is connectivity.

What you need to be sure you have is NetBIOS level connectivity. That is what the LMHOSTS file is going to help you establish.

Brad

[Pieter 't Hart]

Brad, thank you for your response

At this time i have modified the lmhosts-file with what i think to be the right entry
#PRE #DOM:
where is that of the PDC
(i also tried with two different lines for the name and the alias)
result in PWRK$KNBDAEMON_NARCIS.LOG
Tue Nov 11 13:39:13 2003 preloaded nbname VCB at 10.65.0.2
Tue Nov 11 13:39:13 2003 preloaded nbname DRUNEN at 10.65.0.2
[

"net view" displays only the local shares
"net view \\vcb" results in :
>>> NARCIS_$ net view \\vcb
>>> Error 86 has occurred.
>>> The network password entered is incorrect.

net accounts /syncresults in :

>>> NARCIS_$ net accounts /sync
>>> NET2455: The Netlogon service has not been started.
>>> More help may be obtained by typing NET >>> HELPMSG 2455.
>>> NARCIS_$ net start netlogon
>>> NET2187: The service control is busy.
>>> More help may be obtained by typing NET >>> HELPMSG 2187.
>>> NARCIS_$

net error /reverse results in :
>>> NARCIS_$ net error /rev /count:10
>>> Program Message Time
>>> ----------------------------------------->>> NETLOGON 3210 11-11-03 02:02PM
>>> NET3210: Failed to authenticate with VCB, the domain controller for domain >>> BVH.
>>> NETLOGON 3210 11-11-03 02:02PM
>>> NET3210: Failed to authenticate with VCB, the domain controller for domain BVH.


the password for "admin" within pathworks has NOT been changed.
the password for the VMS SYSTEM-account did differ, but making them equal brought no solution.

Pieter

[Antoniov.]

It seems a password problem (as I thought in my prior post).
Admin password not changed but PDC a BDC have different pwd (may be due a some database problem) so when BDC appear to PDC is not recognized and obviously does not recevive security information.

Try to change the password on BDC otherwise execute PWRK$CONFIG to reconfigure BDC.

Bye
Antoniov

[Pieter 't Hart]

Antoniov thanks for your reply.

I allready tried pwrk$config.
I tried again after your post while changeing something.
(in this case i changed the cluster-alias)
still no improvement.

the option of changing role to "standalone" and back to "backup" as mentioned in Edwin's "hints" I also thought of, but is ofcoure a last resort because of the
consequences to the rights on shares.

Pieter

[Edwin Gersbach_2]

Just to make that clear: the culprit is probably the password of the machine account, that is the account for the server itself in the domain. There is a NT tool to have the PDC to resync this password but I don't remember its name. Try the following (which is also in the hints file):

Resynchronize UAS
· on the PW-Server (BDC)
· $ net logon admin passwd
· $ net accounts /role:standalone
· $ lmuser -m "" guest
· on the NT-Server (PDC)
· Using the server manager, remove the computer from the Domain
· Using the user manager, delete the computer account of the BDC
· on the PW-Server (BDC)
· $ pwstop
· $ @sys$update:pwrk$config
· change the admin password to the same as domain admin password (take care of minimum password length of the SYSTEM account)
· $ pwstart
· $ net logon admin passwd
· $ net a

[Pieter 't Hart]

Edwin thank you,
Apearently i wasn't clear that both PDC and BDC are VAX systems running the same version of OS (OpenVMS V6.2) and PATHWORKS (V5.0F) and TCP/IP stack (UCX V4.2).
No Windows-server is involved (only windows-clients).

Making the server standalone and then adding againg to the domain would be a last resort because of the consequences on the file-access-rights.
As i understood when (re)joining a domain the pathworks-server resequences (renumbers) the useraccounts and groups,
so the identifiers in the ACL doesnt match the actual accounts anymore.
wich would result in having to look up all ACL's before executing and resetting all ACL's again to the desired values after.

that's why i turned to this forum to see if some "shortcut" was possible.
if not ...allas!

Pieter

[Edwin Gersbach_2 · Accepted solution]

Well, I never had this situation, but you may try to stop both the PDC and the BDC and then set the machine account password on both servers:
$ lmuser -m "whatever" bdcnam

this might enable the BDC to join the domain again.

Edwin

[Pieter 't Hart]

Edwin,
It's going the right way !!!
It still isn't fully functional
but the important thing replication from the PDC to the BDC is functioning again!

i did a
lmuser -m -p "whatever"
on both systems
this didnt seem to work
so i also (again) did a
lmuser -m -p "" guest
on both systems (as mentioned in a previous response)
after a while monitoring i noticed thad replication DID occure. It took a long time so i'm not sure wich of above command's actually did the job.

I stil get :
NARCIS_$ net view \\vcb
Error 86 has occurred.
The network password entered is incorrect.
from the BDC querying the PDC but thats of minor importance.

Everybody many thanks for your assistance.

Pieter 't Hart