upgrade Pathworks to Advanced Server

[Uwe Zessin]

Is it possible to do a direct upgrade from
Pathworks V6.0C to Advanced Server 7.3A ECO2?

I'm supposed to upgrade a VMS V7.3 system to
V7.3-2 and do the Pathworks upgrade, too.

There is only limited time and the owner might
want to go back to the old version - is there
a way to delay any 'messing with the ACLs'?

[Martin P.J. Zinser]

Hello Uwe,

looks like you should be able to upgrade directly.

Check

http://h71000.www7.hp.com/pathworks/upgrading.html

for details.

Greetings, Martin

[Willem Grooters]

Beware - you 'll probably need new licenses as well.

[Paul Nunez]

Hi,

The "upgrade" doesn't 'mess with the ACLs' (like the v5 to v6 upgrade had to).

In fact, the "upgrade" is done when you first run pwrk$config after the installation. It merely, translates the values in pwrk$lanman:lanman.ini into the appropriate OVMS Registry keys/values (make sure you have the OVMS Registry configured before running pwrk$config by executing sys$manager:reg$config.com).

Besides ensuring you have the correct license, pwlmxxxca07.03, another recommendation is to run SAMCHECK _before_ you install/config AS v7.3A ECO2 to ensure the SAM db files are not corrupt.

$ @sys$startup:pwrk$define_commands
$ pwstop [cluster]
$ samcheck -s

If SAMCHECK reports any corruption, you'll want to correct that first. How you "correct" it depends on the domain role of the v6 server (which wasn't posted).

Best of luck,

Paul Nunez
HP Services

[Uwe Zessin]

Martin,
that is a very useful link, thanks!

Paul,
the VMS system is a BDC for an NT4 PDC.

I have done a short look over the release notes some days ago and I understood that the V7 server is 'reformatting' the ACLs on the fly, no?

The system manager has already made sure that he has the correct licenses, but thanks anyway - it is too easy to forget.

[Paul Nunez]

Hi,

Ah, I see; you're referring to the way the server itself changes the %x80 ACE. That's a good thing and should be very transparent to the users/server...

It's just removing some unneeded data from the ACE to shorten it...

Paul

[Uwe Zessin]

Yes, but we might have to go back to the V6.0C server and so we want to delay that process a while.

[Paul Nunez]

Hi Uwe,

Yes, you can suppress the "upgrading" of the ACEs; see the v7.3a eco2 release notes, section 3.27.

But unless disaster strikes, I would discourage anyone from downgrading back to v6.0c. Especially if they stay with OVMSA 7.3-2 (and especially if they are not currently running ECO2 of v6.0C).

HTH,

Paul

[Antoniov.]

Hi Uwe,
when you upgrade form V6.0C to V7.3 system inquire you if you will save data of V6. I tryed to restore and it works fine. Check for free space so you are sure can coma back!

Bye
Antoniov

[Paul Nunez]

Antonio/Uwe,

>when you upgrade form V6.0C to V7.3 system >inquire you if you will save data of V6. I >tryed to restore and it works fine. Check >for free space so you are sure can coma >back!

Not when upgrading from v6 (that was a feature provided when upgrading from v5 to v6).

The supported way to downgrade from v7 to v6 is to run $ @sys$update:pwrk$deinstal (be sure to indicate that you wish to save the Advanced Server data files) and then install the previous version.

Paul

[Antoniov.]

Hello Paul,
I've upgraded form V6.0C to V7.2 two month ago and the backup feature were active; now in V7.3 is disabled? Why?

Antoniov

[Paul Nunez]

Anontiov,

No change for v7.3A, it's always been that way when upgrading from v6.x to v7.x.

Perhaps you were upgrading from v5 to v7? In order to upgrade the data you would have had to first install v6 (which is where you could preserve the v5 environment) and then run the v6 upgrade procedure(pwrk$v6upgade.com), before installing v7.?.

Paul

[Antoniov.]

Paul,
I've investigated: on ssystem where installed V5.xx of pathworks.
No save environment form V6.
You are right!

Bye
Antoniov

[Paul Nunez]

Hi,

I just realized a mistake I made earlier.

It concerns downgrading. To deinstall v7.3(A), use the command:

$ PRODUCT REMOVE ADVANCEDSERVER

(sys$update:pwrk$deinstal.com is for removing PATHWORKS v6.x and Adv Srv 7.2A).

Sorry for any confusion I caused...


Paul

[Uwe Zessin]

Many thanks for your help. I will start the job tomorrow morning. If you don't hear from me during the next week you know that 'something went wrong and I got toasted' ;-)

[Uwe Zessin]

Well, I didn't get toasted ;-)

Here is a small report in case anyone is interested:

the upgrade of Pathworks and OpenVMS went smooth. There was a problem with TCP/IP V5.4: it looks like it no longer honors the logical name "TCPIP$LPD_PRINTCAP" (I hope I got that name right - I left all logs with the system manager). Instead it requires that the data is stored in SYS$SPECIFIC:[TCPIP$LPD]. I had just copied the file to any specific root and left it at that to continue with the upgrade.

It was very problematic to find this out, because the symbiont did not report the filename. I had attempted to set up file auditing, but we had a client system that was constantly accessing the NFS server on the system that caused lots of audits. In the end I searched and dumped the symbiont's executable and shareable images.

Just before we starting packing we discovered that domain replication from the NT4 PDC to the advanced server BDC did not work (authentication error). They are using a WINS multihomed entry to do load balancing to 2 VMS file servers. WINS is done by an NT4 server.

The system manager had fiddled with the entries and we also tried to convert the BDCs to member servers which he wanted to do anyway. The latter failed with an error message when trying to establish a local SAM. Sorry, I don't have that message - I have asked the system manager to mail the log, but he didn't do yet. Fortunately the procedure reverted to BDC status successfully - good work, Pathworks Engineering!!

Somehow the replication started to work again. We checked everything again and then we left.

On monday morning I got a call that load balancing via WINS did not work - all clients were working on the same server. We were a little puzzled, but I was able to come up with a little diagnostic utility from Microsoft that is named 'NBLOOKUP'.

Indeed, when the system manager tried this he received always the first IP address entry from the WINS server. Again, he deleted and re-entered the entry and suddenly it started to work. I have talked to him yesterday and it appears that the users are much better balanced, now. Apparently not every user logs off over night, but we beleive that 'shakes out' over the next days.

I hope you find that usefull - I always enjoy reading stories that do _not_ end in a total mess ;-)

[Paul Nunez]

Hi Uwe,

Thanks for the update.

Interesting WINS info too. WINS always (used to?) return the list of addresses for a multihomed name to the clients in the same order (sorted by IP address). OTOH, perhaps newer clients are now randomly choosing one from the list returned (older Windows clients always seemed to use the first address in the list, thereby negating load balancing)...

Paul

[Doug Phillips]

>Paul Nunez wrote:
>
>If SAMCHECK reports any corruption, you'll >want to correct that first. How >you "correct" it depends on the domain role >of the v6 server (which wasn't posted).
>

Paul,

If the PDC is a W2K and the PW6 is a BDC and SAMCHECK finds a problem, then the only way we found to successfully upgrade to 7.3A2 is to first leave the domain and become a PDC of a dummy domain. Do the upgrade. Then rejoin the original domain.

The release notes do explain the SAM corruption problem but I didn't find anything that gave me the above information. Maybe knowing this will help some else.

Doug

[Paul Nunez]

Hi Doug,

I should have been more specific. Your method is the only way to rebuild the SAM, but you can circumvent the need to change domains/roles, by first renaming some files:

$ rename/excl=*.dir pwrk$lmdomains:*.* *.old
$ set def pwrk$lmdatafiles:
$ rename acl. *.old
$ rename builtin. *.old
$ rename lsa. *.old
$ rename sharedb *.old
$ rename chglog.lmx *.old

Then run pwrk$config. When you get to the menu where you change the domain name and role, the domain name will still be the original domain (no change required); but the role will indicate PDC, change it to the proper role and answer the remaining prompts to rejoin the domain. At the end of pwrk$config it will ask if you want to start the server; tell it no.

Once back to DCL, you'll want to restore your ACL. and SHAREDB. files to get your share definitions and share permissions back:

$ rename acl. *.new
$ rename sharedb. *.new
$ rename sharedb.old *.
$ rename acl.old *.

Then you can start PATHWORKS/Advanced Server. In the case of a BDC, it will take some time for the full sync of the SAM, LSA, and BUILTIN databases to complete (check the system event log for applicable messages).

In your case Doug, since you ran pwrk$config and changed domains, it would have stored the original files in subdirectories under pwrk$lmdomains: and pwrk$lmdatafiles: (in case you still need to recover your sharedb and acl files).

HTH,


Paul

[Doug Phillips]

Paul,

Yes, I see what you mean. However, by changing off to another domain we kept our sharedb and acl files intact and allowed the upgrade to do whatever updating it needed to those files (we didn't know, maybe none was needed?). And, the way we did it was a whole bunch easier and less fumble-fingerable, I think. We did read Section 3.7 of the Inst & Config Guide a few times before deciding our approach would be safe.

To clarify your instructions a bit, though:

> Once back to DCL, you'll want to restore
> your ACL. and SHAREDB. files to get your
> share definitions and share permissions
> back:
>
> $ rename acl. *.new
> $ rename sharedb. *.new
> $ rename sharedb.old *.
> $ rename acl.old *.

======
Is this where you would do the 73A2 upgrade?
======

> Then you can start PATHWORKS/Advanced
> Server. In the case of a BDC, it will
> take some time

Because when the V6 server is restarted, the W2K server will corrupt our SAM when it syncs.

With a corrupt SAM, after the upgrade, PWRK$CONFIG -> PWRK$SETINI runs SAMCHECK and errors out before the configuration menu is displayed. We could find no way around this other than to restore back to V6 and study the problem until we arrived at the domain leave/upgrade/rejoin solution.

BTW, is SAMCHECK going to be "supported" soon? It seems to have some switches that don't show up in help, and not all of the the switches in the Unix version are there.

Thank you.

Doug

[Paul Nunez]

Hi,

>To clarify your instructions a bit, though:

>> Once back to DCL, you'll want to restore
>> your ACL. and SHAREDB. files to get your
>> share definitions and share permissions
>> back:
>>
>> $ rename acl. *.new
>> $ rename sharedb. *.new
>> $ rename sharedb.old *.
>> $ rename acl.old *.
>
>======
>Is this where you would do the 73A2 >upgrade?
>======

I suppose you could, but I've never tried it :). But...

>> Then you can start PATHWORKS/Advanced
>> Server. In the case of a BDC, it will
>> take some time
>
>Because when the V6 server is restarted, >the W2K server will corrupt our SAM when >it syncs.

Consistently? Every time? We should fix that :). That shouldn't happen. There's likely some account that is (1) corrupt in the w2k server, (2) has some unusual data associated with it that is being passed to PATHWORKS that PATHWORKS can't store it its SAM, or (3) an account name (user or group) is too long.

If it happens consistently, I would get a trace. We should be able to figure out the offending account at least:

$ tcptrace/full/packet=100000/out=x.x

>With a corrupt SAM, after the upgrade, >PWRK$CONFIG -> PWRK$SETINI runs SAMCHECK >and errors out before the configuration >menu is displayed. We could find no way >around this other than to restore back to >V6 and study the problem until we arrived >at the domain leave/upgrade/rejoin >solution.

Right on target, there. A corrupt sam will cause pwrk$config to error out. But now that you're at v7.3A ECO2, you no longer get a corrupt SAM?

>BTW, is SAMCHECK going to be "supported" >soon? It seems to have some switches that >don't show up in help, and not all of the >the switches in the Unix version are there.

No plans that I'm aware of. The good news is, as of v7.3A, you can use the -r switch to repair a corrupt SAM.

Paul

[Doug Phillips]

Hi Paul,

Yes, this particular Win2000 server corrupted this particular PWv6.1 server's SAM everytime as far as SAMCHECK was concerned. Otherwise, The two servers got along just fine and seemed to accept their differences.

The ASOVMS v7.3A2 Release notes do address the issue and that helped. Nothing we found really explained the workaround to the problem, though. See:

6.6.2 SAM Database Corrupted After Server Joins Windows 2000

So, 7.3AECO2 runs just fine and the problem does indeed appear to be solved. Thankfully, there is only one other PWv6 server we have to deal with and now I suspect that upgrade will go easier.

Thanks for the feedback. This has helped me understand Advanced Server much better.

Doug

[Uwe Zessin]

I have been a bit busy, but the customer has not reported any problems.

Paul,

25.Feb: we had done a small test on an old Alpha-based NT 4.0 server and it showed the same, but he claims it is now working, after he had re-entered the addresses at the WINS server.


I have done another upgrade last weekend and set up a small Advanced Server config with the licenses that came with the server so he can test it. The [other] customer was quite impressed. Hey, you might have a new customer in the future!