I have a netware 4.11 server (SP 9, DS 6.21, DSREPAIR 4.73a)that runs Groupwise 5.26, DNS 4.01a (Unicon 5.18), DHCP 2.10r, PSERVER 5.00, is a Norton Antivirus distribution server, and has a couple of volumes for file storage. I need to migrate to a new IBM x235 with NW5.1, and then in place upgrade to NW6. There is one other NW4.11 server running a Groupwise mail gateway. My thoughts are to down the Gateway so as not to be updating mailboxes while the migration is in progress. I also want to stop Norton, Powerchute (UPS Monitor), and Backup Exec from the server to be migrated. Is this a good course of action? Should I unload the Print Server and Groupwise also or should I leave everything running? Eventually the IBM Netfininty 5500 that is being migrated will in turn replace the antique that is now the Gateway. I have already tried this operation four times on one weekend with no success (the servers seemed to lose communication with each other during the early part of the process and hang). They are on separate ports of a Cisco WS-C2924-XL switch. I now think it was a reference to a test server that doesn't exist any longer. It has been deleted through NDSMGR32 (it would not delete from NDSMGRNT). When I do this again (it will be an all nighter to start a weekend), I want to have all bases covered. Sorry to ramble on. Any suggestions are appreciated.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
4.11 to 5.1 to 6 migration/upgrade questions
- Thread starter kdeans
- Start date
marvhuffaker
MIS
From what you are saying, I think you need to worry more about the health of your tree than with the apps that are running on top.
DS health is most critical when doing migrations. Check your time and replica synchronization, and make sure your tree is clean. And make sure you can maintain a solid connection till it's done. You can find TIDs about this on Novell's support site. Look up "HEALTH CHECK"
Also, if you're using the migration wizard, you might want to consider other options for copying the files. I've had pretty bad luck in general with the copy files function of the Migration Wizard.
Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting
DS health is most critical when doing migrations. Check your time and replica synchronization, and make sure your tree is clean. And make sure you can maintain a solid connection till it's done. You can find TIDs about this on Novell's support site. Look up "HEALTH CHECK"
Also, if you're using the migration wizard, you might want to consider other options for copying the files. I've had pretty bad luck in general with the copy files function of the Migration Wizard.
Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting
- Thread starter
- #5
Thanks Marv and others,
I have run and did run DSREPAIR a number of times in preparation for the first attempts and made sure that the new server clock was slightly ahead of the old server. I couldn't get rid of a server object for a test server in the tree by using NDSMGRNT. It was only after the failure that I tried NDSMGR32 and was successful. If I have similar problems with communication on the next attempt, I will put both servers and one workstation on a hub connected to nothing else and see where that takes me. I am using Migration Wizard 6.5.308.8 (latest from Novell). I think that I will try to migrate only NDS and the SYS volume and if all goes well then I will bring the old server up with a temp name and copy the other volumes.
I have run and did run DSREPAIR a number of times in preparation for the first attempts and made sure that the new server clock was slightly ahead of the old server. I couldn't get rid of a server object for a test server in the tree by using NDSMGRNT. It was only after the failure that I tried NDSMGR32 and was successful. If I have similar problems with communication on the next attempt, I will put both servers and one workstation on a hub connected to nothing else and see where that takes me. I am using Migration Wizard 6.5.308.8 (latest from Novell). I think that I will try to migrate only NDS and the SYS volume and if all goes well then I will bring the old server up with a temp name and copy the other volumes.
marvhuffaker
MIS
Don't take this the wrong way, but from the responses you have given, it is obvious that you do not have the level of expertise that might be necessary to do a successful migration. It's much more complex than that. I fear that you are going to be very frustrated when you have to keep backing out because "Something" isn't working and DSREPAIR isn't fixing it.
You need to read through Novell's documentation and understand the processes, or call someone in that can help you with it. The documentation on Novell's site is pretty comprehensive.
Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting
You need to read through Novell's documentation and understand the processes, or call someone in that can help you with it. The documentation on Novell's site is pretty comprehensive.
Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting
- Thread starter
- #7
Marv,
I am a CNE 4 and have taken the upgrade courses for both 5 & 6 a number of years ago but I am the sole person responsible for a LAN/WAN that covers 19 locations and just under 200 desktops of every flavor. I built this network about eight years ago. It has been relatively bullet-proof. Only a couple of Netware servers as described earlier but the last migration I did was four or so years ago to upgrade the hardware only. If you never do it, you don't know what to expect no matter how much you read. The documentation offered by Novel and IBM fails to cover all but the most common or obvious errors. It's lonely at three in the morning when something unexpected happens and you have only the internet to help. This is why I have relied on people who may do this many times and have experienced a wider array of problems and solutions. Unfortunately my experience is with one employer and therefore one hardware / software configuration. It's good until you need to change that comfortable configuration. When I said that I ran DSREPAIR a number of times, I mean that I run it regularly. The server object appeared only in NWADMIN where it could not be deleted. It didn't appear in the NT version of DS Manager but showed up in the Win95/98 version where I could finally blow it away. Anyway, I had hoped to sound cautious and not inexperienced. Thanks again.
I am a CNE 4 and have taken the upgrade courses for both 5 & 6 a number of years ago but I am the sole person responsible for a LAN/WAN that covers 19 locations and just under 200 desktops of every flavor. I built this network about eight years ago. It has been relatively bullet-proof. Only a couple of Netware servers as described earlier but the last migration I did was four or so years ago to upgrade the hardware only. If you never do it, you don't know what to expect no matter how much you read. The documentation offered by Novel and IBM fails to cover all but the most common or obvious errors. It's lonely at three in the morning when something unexpected happens and you have only the internet to help. This is why I have relied on people who may do this many times and have experienced a wider array of problems and solutions. Unfortunately my experience is with one employer and therefore one hardware / software configuration. It's good until you need to change that comfortable configuration. When I said that I ran DSREPAIR a number of times, I mean that I run it regularly. The server object appeared only in NWADMIN where it could not be deleted. It didn't appear in the NT version of DS Manager but showed up in the Win95/98 version where I could finally blow it away. Anyway, I had hoped to sound cautious and not inexperienced. Thanks again.
marvhuffaker
MIS
I apologize if that was taken wrong. Many people are in the same situation. Pretty static network, and one lone admin to take care of everything.
As I seem to say more and more often.. The most important thing in a migration is to make sure DS is healthy. From your previous posts, it's hard to know if you understand this process or not. Your replica rings have to be consistent, you can't be getting sync or time errors, and these are things you don't find in NWADMIN or NDSMGR.
When your DS is unhealthy, that is what causes a migration to fail most of the time. I can't even count how many times I've been called in after a failed migration, only to find out that the company had no concept of health checks or synchronization. In every scenario, after DS was fixed and things healthy again, the migration went as planned.
So for starters, you need to start doing health checks. You can do one right now, tomorrow, the next day.. You can't do them too often, and as you do them you will start to notice what to look for and how to tell when things look wrong or out of whack.
The following steps will do a very BASIC health check but will get you started in the right direction. Many problems can be found in these steps:
DSREPAIR --- TIME SYNCHRONIZATION... All servers should report that their time is synchronized. If they don't, find out why not and get them in synch.
From The Console:
SET DSTRACE=ON
SET DSTRACE=+S
SET DSTRACE=*H
Switch the screen to the DIRECTORY SERVICES Trace screen... If you see any RED numbers go by, you need to look and find out what they are and if they are a problem. In general, they will show up as -601 or -672. Something like that. Usually if everything is healthy, you will not see any errors like that and you'll see lots of GREEN stuff, and eventually an "ALL PROCESSED=YES" for each partition that your server has a replica of.
Also, about the server clock.. Did you read that somewhere to put it ahead? I usually synch the destination server to the source. And I make sure they're both reporting their time is synchronized before moving forward.
Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting
As I seem to say more and more often.. The most important thing in a migration is to make sure DS is healthy. From your previous posts, it's hard to know if you understand this process or not. Your replica rings have to be consistent, you can't be getting sync or time errors, and these are things you don't find in NWADMIN or NDSMGR.
When your DS is unhealthy, that is what causes a migration to fail most of the time. I can't even count how many times I've been called in after a failed migration, only to find out that the company had no concept of health checks or synchronization. In every scenario, after DS was fixed and things healthy again, the migration went as planned.
So for starters, you need to start doing health checks. You can do one right now, tomorrow, the next day.. You can't do them too often, and as you do them you will start to notice what to look for and how to tell when things look wrong or out of whack.
The following steps will do a very BASIC health check but will get you started in the right direction. Many problems can be found in these steps:
DSREPAIR --- TIME SYNCHRONIZATION... All servers should report that their time is synchronized. If they don't, find out why not and get them in synch.
From The Console:
SET DSTRACE=ON
SET DSTRACE=+S
SET DSTRACE=*H
Switch the screen to the DIRECTORY SERVICES Trace screen... If you see any RED numbers go by, you need to look and find out what they are and if they are a problem. In general, they will show up as -601 or -672. Something like that. Usually if everything is healthy, you will not see any errors like that and you'll see lots of GREEN stuff, and eventually an "ALL PROCESSED=YES" for each partition that your server has a replica of.
Also, about the server clock.. Did you read that somewhere to put it ahead? I usually synch the destination server to the source. And I make sure they're both reporting their time is synchronized before moving forward.
Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting
marvhuffaker
MIS
kdeans, I found this tid that is VERY comprehensive and goes into great explanation about health checks. You should get familiar with it before your upgrade, and continue to use it long aftwarwards.
Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting
Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question