IPrint migration from Netware to OES 11.1...

Hi,
I'm trying to migrate printer agents from a Netware 6.5 SP8 machine to a print manager running on OES 11 SP1 (on SLES11 SP2).
When migrating the printer agent, all goes well with the exception of printer driver associations - which aren't made for the newly -created queue.
The Netware print manager is running the "6e" set of patches and the OES 11.1 server has the Sept 2013 patch set.
I found another thread which mentioned that disabling the proxy on the server resolved this. I've tried disabling the system proxy and restarting, but this hasn't made a difference.
The migration log doesn't mention any failures to associate printer drivers.
Has anyone else seen this, and if so have you found a workaround/fix for this? We have 1300 printer agents, so manual association isn't an option :)
Thanks in advance,
Matt

On 11/04/2013 04:54 PM, sisml wrote:
>
> Hi,
>
> I'm trying to migrate printer agents from a Netware 6.5 SP8 machine to a
> print manager running on OES 11 SP1 (on SLES11 SP2).
>
> When migrating the printer agent, all goes well with the exception of
> printer driver associations - which aren't made for the newly -created
> queue.
>
> The Netware print manager is running the "6e" set of patches and the OES
> 11.1 server has the Sept 2013 patch set.
>
> I found another thread which mentioned that disabling the proxy on the
> server resolved this. I've tried disabling the system proxy and
> restarting, but this hasn't made a difference.
>
> The migration log doesn't mention any failures to associate printer
> drivers.
>
> Has anyone else seen this, and if so have you found a workaround/fix for
> this? We have 1300 printer agents, so manual association isn't an option
> :)
>
> Thanks in advance,
>
> Matt
>
>
you should follow this steps to disable proxy if you do not want to
reboot the server:
- Turn off the proxy:
YaST -> Network Services -> Proxy -> Uncheck the "Enable Proxy" option
- Server console type :
# unset http_proxy
# unset https_proxy
# rcapache2 restart
Try it again

Similar Messages

Migrating from Netware to Linux - faster "sync" ?

Hey all,
Planning on doing a TransferID migration from netware 6.5 to linux this weekend and have done some trial data copies.. Main copy is already done, but the "sync" is still taking a large number of hours that I need to try and fit into a smaller window. Any tips on getting sync to go faster? I'm currently using the miggui but wondering if you do the commands manually, leaving things out like displaying progress bar, etc.. if it'll get to it quicker.

Originally Posted by joebrug
Hey all,
Planning on doing a TransferID migration from netware 6.5 to linux this weekend and have done some trial data copies.. Main copy is already done, but the "sync" is still taking a large number of hours that I need to try and fit into a smaller window. Any tips on getting sync to go faster? I'm currently using the miggui but wondering if you do the commands manually, leaving things out like displaying progress bar, etc.. if it'll get to it quicker.
So, we have 6-year old HP DL-385 (no G, that's old they are) that are slower than you know what.
We're migrating to HP DL385 G6 or G7, but we're using VMware ESXi, so the target OES11 server is a Guest VM.
Both servers are on a gigabit switch.
We average approx. 15-20 GB/hour (it's not the AMOUNT of data, it's how many small files that affects things).
We're able to get the sync to fit in a small window (even our large ones, maybe 2-4 hours).
Is that not fast enough (although you may have LOTS more small files that change daily).
Basically we cart the server down, run the sync during the day until it finishes. Obviously it skips things that were in use. Then we kick everyone off the server at 3:00 and start the sync.
Since you're on NetWare to OES, I would NOT recommend rsync. The rsync on NetWare is very touchy/finicky and I don't think you can migrate trustees either.
From OES2 to OES11, you could use rsync, although I'm having mixed results with the trustees at the moment.
One thing we DO have is a "static" set of read-only data on the server, that we do NOT migrate over. We have a central office server that contains the "master" data and the clients run rsync to pull the data. So we don't even back it up either (other than the main office).
I can't remember the EXACT numbers we got when we did NetWare to OES2, but I still think we were averaging somewhere around 12-17GB/hour depending on. The key point was to make sure you were gigabit and didn't have a mis-match because someone in your datacom unit set the **** switch to 100-full or something other than auto-auto.
Oh, and if you have disk quotas, make sure that you either clear them or keep compression enabled. THAT will slow things down because if it tries to copy something, and there's not enough space, it'll retry like X times and then continue on and you find out like 10 hours later it was slow because you didn't have enough directory quota space.

IPrint migration from NW 6.5 to SLES fails

Using SCMT 1.1 to migrate from Netware 6.5 to SLES. Migration works
perfectly, except for iPrint. We're getting the error detailed in TID
10098587, but the "fix" it shows doesn't work. We just want to copy the
existing PAs to the new Print Manager running on Linux (same tree,
different context).
Anyone else seen this?
Thanks.
Mark Hepinstall, MCNE

That seems contrary to the documentation. I couldn't find anything on
moving a Print Manager from Netware to SLES. That was originally my
thought as well, as I've done lots of server-to-server NDPSM moves
without any problem, but there doesn't appear to be a documented method
for moving an NDPSM from Netware to SLES. Also, in this particular
case, the client is trying to build a "parallel" setup for testing
before they actually execute the final migration and cutover.
Thanks.
Mark
Louis-Steve Desjardins wrote:
> Yeah we had this problem. It seem you can't move just PA. It works great
> when you move the whole Print Manager. So delete your print manager on SLES
> and move your Print Manager.
>
> Louis-Steve Desjardins
>
> "Mark Hepinstall" <[email protected]> a crit dans le message de
> news: WpCJg.1566$[email protected]..
>> Using SCMT 1.1 to migrate from Netware 6.5 to SLES. Migration works
>> perfectly, except for iPrint. We're getting the error detailed in TID
>> 10098587, but the "fix" it shows doesn't work. We just want to copy the
>> existing PAs to the new Print Manager running on Linux (same tree,
>> different context).
>>
>> Anyone else seen this?
>>
>> Thanks.
>>
>> Mark Hepinstall, MCNE
>
>

Upgrade and migration from Netware to Linux best practice

Hi folks,
We've been running NSM 2.5 for a few years on Netware and have been very satisfied with the product and performance. We are planning to migrating to SLES11 with OES11 very soon to finally move away from Netware and I have some issues I can't seem to find answers to. Of course I want to use NSM to move my home directories from my Netware to my SLES so I want this working well when we migrate.
I've searched but not found a good resource to show how to move the NSM engine from a Netware server to a Linux server with best practices. Anyone have experience with this and any gottchas?
The other question is of course is to upgrade NSM to a new version before or after the move to Linux/OES11? We are at Ver 2.5.0.43 and want to move to the latest version. Upgrade procedure and best practices would be handy.
The last of course is NSM compatible with SLES/OES11? I presume it is and certainly hope so because we want to move all of our users to SLES11 NSS.

On 5/9/2012 11:06 AM, jlauzon wrote:
>
> Hi folks,
> We've been running NSM 2.5 for a few years on Netware and have been
> very satisfied with the product and performance. We are planning to
> migrating to SLES11 with OES11 very soon to finally move away from
> Netware and I have some issues I can't seem to find answers to. Of
> course I want to use NSM to move my home directories from my Netware to
> my SLES so I want this working well when we migrate.
> I've searched but not found a good resource to show how to move the NSM
> engine from a Netware server to a Linux server with best practices.
> Anyone have experience with this and any gottchas?
The NSM 3.0.x Engine setup process actually handles the migration from
NSM 2.5 fairly easily. Our 3.0 Installation Guide (available at
http://www.novell.com/documentation/storagemanager3 ) includes all the
information you should need regarding migration, including the
suggestions I'll list here.
You'll want to leave NSM 2.5 running during the migration so that the
NSM 3.0 setup wizard can connect to that Engine and import its policies
and pending events. You'll also want to have as few pending events as
possible in NSM 2.5 -- deferred deletes are fine, but all pending events
will slow down the migration process, since they'll have to be
transferred over.
> The other question is of course is to upgrade NSM to a new version
> before or after the move to Linux/OES11? We are at Ver 2.5.0.43 and want
> to move to the latest version. Upgrade procedure and best practices
> would be handy.
Again, this information is available in the 3.0 Installation Guide. To
migrate from 2.5 to 3.0.x, you'll have to have at least one OES11 server
in your tree to install it on; but you'll also have to leave the NSM 2.5
Engine running on its Netware host long enough to migrate from it.
> The last of course is NSM compatible with SLES/OES11? I presume it is
> and certainly hope so because we want to move all of our users to SLES11
> NSS.
We are about to release version 3.0.4 of NSM, which provides full
support for OES11 on SLES11. The NFMS Support Team can also provide you
with builds of NSM 3.0.3 which support OES11; if you need those for
early testing, please send an email to storagemanager[at]novell[dot]com.
Hope this helps!
- NFMS Support Team

Migration from Netware 6.x NSS to Solaris 10 ZFS

Hi,
I am looking at Solaris and ZFS as being the possible future of our file store for users.
We have around 3TB (40million files) of data to transfer to ZFS from Netware 6.5 NSS volumes.
What is the best way to do this?
I have tried running utilities like richcopy (son of robocopy) , teracopy, fastcopy from a Windows client mapped to the Netware server via NCP and the Solaris server via Samba.
In all tests the copy very quickly failed, rendering the Solaris server unusable. I imagine this has to do with the utilities expecting a destination NTFS filesystem, and ZFS combined with Samba does not fit the bill.
I have tried running the old rsync client from Netware, but this does not seem to talk to Solaris rsyncd.
As well as NCP, Netware has the ability to export its NSS volumes as a CIFS share.
I have tried mounting a CIFS share of the Netware volume on Solaris...but Solaris as far as I am aware does not support mount -t smbfs as this is Linux only. You can mount smb:// from the Gui (Nautilus), but this does not help a great deal. I was hoping to run maybe Midnight Commander, but I presume that I would need a valid smb share to the Netware volume from the command line?
I really want to avoid the idea of staging on say NTFS first, then from NTFS to ZFS. A two part copy would take forever. It needs to be direct.
BTW..I am not bothered about ACL's or quota. These can be backed up from Netware and reapplied with ZFS/chown/chmod commands.
A wild creative though did occur to me as follows -
Opensolaris, unlike Solaris, has its CIFS kernel addition, and hence smb mounts from the command line (I presume), but I am not happy running opensolaris in production.So maybe I could mount the Netware NSS volume as a CIFS share on opensolaris (as a staging server), copy all the data to a ZFS pool locally, and the do a send receive to Solaris 10.......
Maybe not...
I suppose there is FTP, if I can get it to work on Netware.
I really need a utility with full error checking, and that can be left unattended.
Any ideas?

Bu unusable I mean that the mapped ZFS Samba drive to the windows workstation died and was inaccessible.
Logging onto the solaris box after this from the console was almost impossible. There was a massive delay. When I did log in there appeared to be no network at all. There were no errors in the smbd log file. I need to look at other logs to find out what is going on. Looking at the ZFS filesystem some files had copied over before it died.
After rebooting the Solaris box I then tried dragging and dropping the same files to the ZFS filesystem with the native windows expolrer interface on the windows client. This worked, as in the Solaris box did not die and the files were copying happily (until I manually stopped it). As we all know Windows explorer is not a safe unattended way to copy large amounts of files.
This tells me that the copy utilities on Windows are the problem, not native windows copy/paste.

IPrint Migration from OES1LX to OES2LX failed

hy,
i want to migrate some printer agents from my oes1sp2lx box to a new oes2sp2lx box.
in the migration tool i always get an error:
2010-01-13 11:11:38,942 INFO - IPRINT:/opt/novell/bin/iprintmig:Information: Trying to get XML from source server
2010-01-13 11:11:43,767 FATAL - IPRINT:/opt/novell/bin/iprintmig:Fatal(13): Unable to get source XML data from server: 401 Authorization Required
2010-01-13 11:11:44,095 INFO - IPRINT:/opt/novell/bin/iprintmig:
2010-01-13 11:11:44,096 ERROR - IPRINT:iprintmig:iprintmig command failed!
Has anyone any idea?
Thx

Hi,
This reports of an authorization failure while running the ncpshell command.
A more detailed log would explain things better. We have few questions. Please can you do the following things:
1. Check the ndps folder in your source NetWare server. See whether the psminfo.nlm and psminfo.xml file exist there or not.
2. Check the debug.log of the migration project. Find out whether there are any other failures prior to this or not.
Please run the following 2 commands manually:
/opt/novell/ncpserv/sbin/ncpshell --ip=<IP address> --u=<user name> --put --src=/opt/novell/iprint/share/PSMInfo.nlm --dst=SYS:/NDPS/PSMInfo.nlm --d
/opt/novell/ncpserv/sbin/ncpshell --ip=<IP address> --u=<user name> --invoke --parm1=SYS:/NDPS/PSMInfo.nlm
Let us know whether you hit a failure or not.
If you want to completely avoid the use of ncpshell command itself follow TID 7004910 to overcome this issue.
Thanks,

Help! Virtualze/migrating from Netware 6.0 + DirXML1.1a

Hi,
Background: We are in the process of rolling out IDM361 to our production environment. We have a mix of Netware 5, 6, 6.5 and Linux OES2 servers. We use DirXML1.1a to sync with MAD (Windows 2000 Servers) and IDM361 is replacing this.
Problem: The server that runs DirXML1.1a is on Netware 6.0. We do not want to break this system as it currently manages user and password sync to MAD. But we also need to roll out "Universal Password" to enable IDM361 to perform the same user and password sync. We don't want to perform a BIGBANG cutover if it can be avoided!!
Request: What we're looking for is some suggestions (and comments) on how to proceed with the Netware 6.0 box. Below are a few we have come up with...
Possible scenarios:
#1 - Virtualize the Netware 6.0 box, then upgrade to Netware 6.5 and hope that DirXML1.1a doesn't break. What products can we use to do this? Platespin and Portlock have been mentioned.
#2 - Build from scratch a new Netware 6.5 box with the same name. Install DirXML1.1a, replicate partitions and import the old drivers. Remove old Netware 6.0 box and join new Netware 6.5 box to the tree then hope and pray that it works.
#3 - Prepare for a long DirXML1.1a outage. Remove Netware 5 and 6 boxes from the tree, stop the sync and roll out "Universal Password". Fire up IDM361, apply the user and password sync policies and migrate all users.
As mentioned before, we would prefer to run both systems in parallel and slowly migrate users across the IDM361 if possible. I know that Netware 6.0 is no longer supported so that's why we are looking to the forums for answers.
Many thanks!
Andrew Tan..

If name is not an issue, you can likely set up your replacement server
with the latest IDM and have it sync only one of container with AD as a
test and leave the old setup in place, until you're ready to cut over.
I'm sure a fair number of people have had to do the same in the past - I
have some customer gone through similar but they didn't have to make such
a drastic jump from DirXML 1.1a ... but I'm not a liberty to discuss those
due to confidiality.
Peter
eDirectory Rules!
http://www.DreamLAN.com

GW801 Primary Domain Netware to OES migration failure

I have started migrating my GroupWise from NetWare to OES. I have migrated a small post office to a server with no problems. I have created a new domain and webaccess on another OES server. My problem came when trying to migrate my primary domain from NetWare to OES. I used the migration utility from the same NetWare server and to the same OES server the small post office I migrated earlier. The migration utility ran without errors. I manually changed the IP's in the Domain and Link configuration, and also I have a startup MTP in our main post office to the primary domain which I changed (I needed this when running on the NetWare Cluster). I ran a database recover DB before and after the migration. All links were green but no traffic from post office to migrated domain or gwia domain to primary domain, queues were filling up. I was running out of time so had to revert back to the NetWare server. I changed the IP's in the Domain object and Links, and MTP on PO, ran DB recover again. Now it wouldn't work on the NetWare server. Luckily I ran a DBCOPY to another source before migrating. I copied over top the domain directory and that saved me.
Any ideas???
I'm running OES with NSS and long name support because I didn't want to deal with administration compatibility issues. I didn't have any problems using my workstation ConsoleOne for the small post office and new webaccess domain. But should I have been using ConsoleOne on the OES server?
On the NetWare server I had in the startup files "Remote Connections" user and password. These are NLM settings and error out when using them on OES. Do I still need a "Remote Connections" user for OES?
If I'm using long name space on the NSS volume do I have to worry about case sensitivity? I'll just copy the files over manually.
Unrelated
The default agent file and log locations are in /opt and /var. I would prefer to have these on my NSS volume. Is this good practice for OES?

kjhurni, thanks for your response. I hope this reply looks correct. I'm reply via my GroupWise Client. For some reason I have a problem with replying via the browser.
I figured the agents would have to stay put if I didn't want to deal with update issues in the future. I think I'll move my logs.
I used the GroupWise Migration utility. Actually I tried again last night with no luck again. The link configuration changes I know that the PO is trying to connect. Here is part of the log file.
06:32:36 094 MTP: GW HCH: Unable to open connection [8925]. Address = 10.0.59.210, Port = 7100
The Primary Domain thinks all is well when looking at the screen. Because it shows all PO's and Domains open. The Secondary Domain shows Primary is down.
I have been using the Migration utility because of the case issues. Which when I tried Dbcopy it didn't seem to change the files to lower case. I think I figured this out and that I need to have Unix name space running and not long. Otherwise it won't make it lowercase.
I just have a Training PO on this server, no MTA.
Do you think I should add secondary IP addresses for POA and MTA agents on the same server?
I do use odd ports for my secondary MTA's because they still run on a NetWare cluster.
Yes, I'm using OES/NSS and ConsoleOne on Windows. I have many administrators that I didn't want to educate, that's why I didn't go SLES.
This is my plan for my third try.
Change the volume name space to unix on destination server.
Make normal dbcopy on original server (This is what saved me the last two times).
Change ConsoleOne Domain and MTA paths.
Stop MTA
Use DBCOPY -m (it will probably work now that I'm using unix name space).
Delete mslocal, wpcsin and wpcsout folders.
Start MTA
Check Links and change If needed.
If I cannot get it to work. Perform a top down rebuild.
What do you think?
>>> On 3/31/2010 at 1:56 PM, kjhurni<[email protected]> wrote:
kwhite;1953211 Wrote:
> I have started migrating my GroupWise from NetWare to OES. I have
> migrated a small post office to a server with no problems. I have
> created a new domain and webaccess on another OES server. My problem
> came when trying to migrate my primary domain from NetWare to OES. I
> used the migration utility from the same NetWare server and to the same
> OES server the small post office I migrated earlier. The migration
> utility ran without errors. I manually changed the IP's in the Domain
> and Link configuration, and also I have a startup MTP in our main post
> office to the primary domain which I changed (I needed this when running
> on the NetWare Cluster). I ran a database recover DB before and after
> the migration. All links were green but no traffic from post office to
> migrated domain or gwia domain to primary domain, queues were filling
> up. I was running out of time so had to revert back to the NetWare
> server. I changed the IP's in the Domain object and Links, and MTP on
> PO, ran DB recover again. Now it wouldn't work on the NetWare server.
> Luckily I ran a DBCOPY to another source before migrating. I copied
> over top the domain directory and that saved me.
>
> Any ideas???
> I'm running OES with NSS and long name support because I didn't want to
> deal with administration compatibility issues. I didn't have any
> problems using my workstation ConsoleOne for the small post office and
> new webaccess domain. But should I have been using ConsoleOne on the
> OES server?
> On the NetWare server I had in the startup files "Remote Connections"
> user and password. These are NLM settings and error out when using them
> on OES. Do I still need a "Remote Connections" user for OES?
> If I'm using long name space on the NSS volume do I have to worry about
> case sensitivity? I'll just copy the files over manually.
>
> Unrelated
> The default agent file and log locations are in /opt and /var. I would
> prefer to have these on my NSS volume. Is this good practice for OES?
NSS is fine, but you can't really change the location of the agent
files. Log files, yes, but the agents and startup files are going to be
in the /opt/novell/groupwise/agents/bin and /share directories
Anyway, back to your question
You used which migration utility? the OES Miggui or the groupwise
migration utility?
I personally just do a dbcopy if it's an MTA as it'll do everything I
Need it to do.
On the destination OES2 server, you mentioned you had a PO on it. Did
you also have another MTA on that as well?
The only time I've seen issues is when you have multiple agents on
OES2. At that point you'll need to use dedicated IP's (there's a
problem it seems where Groupwise doesn't pay attention to the "bind to
specific" IP if it's running on Linux/OES2).
Also, I've had an issue where the stupid MTA had a "bad" configuration
(odd port # leftover from WAY back when) and no amount of rebuilding
would fix it. I ended up having to manually edit the startup file to
force it to use the configured IP and Port.
Then I stopped/started the MTA and it stayed loaded. Then I
stopped/started the POA and it loaded.
Then a few minutes it got communication to each other and seemed to
behave properly from that point on.
I am assuming that you are using NSS on your OES2 server and using
ConsoleOne on a Windows machine (as opposed to running on the actual
OES2 server itself).
kjhurni
kjhurni's Profile: http://forums.novell.com/member.php?userid=734
View this thread: http://forums.novell.com/showthread.php?t=405860

IPrint Migration - Printers and Clients Not on Welcome Page

We just finished a test migration of one of our iPrint servers from Netware 6.5SP8 to OES 11SP1. Everything went well, the driver store and manager are up and working, all the printers migrated, and all the drivers seem to be there. The one annoying issue is that the client download links and the install printers links did not get added to the Client Software tab on the default OES home page. I restarted all the services, but they still do not show up. If I type in the client download link manually, I can download it. I can also access the printers page directly at server/ipp. What do I need to do to get those links to appear?
Thanks,
Jason

On 02/11/2013 11:16 PM, jmlester wrote:
>
> We just finished a test migration of one of our iPrint servers from
> Netware 6.5SP8 to OES 11SP1. Everything went well, the driver store and
> manager are up and working, all the printers migrated, and all the
> drivers seem to be there. The one annoying issue is that the client
> download links and the install printers links did not get added to the
> Client Software tab on the default OES home page. I restarted all the
> services, but they still do not show up. If I type in the client
> download link manually, I can download it. I can also access the
> printers page directly at server/ipp. What do I need to do to get those
> links to appear?
>
> Thanks,
> Jason
>
>
Being in the welcome page, client software tab, if you check the source
of the html page or the javascript on the page, you should see a
http://servername/welcome/links/iprint.js.
If not, the migration did not copied the file. If it is, check it is the
one from oes11 and not from netware. Installing latest oes11sp1 iprint
modules should restore the good iprint.js.

Can't convert case after moving a GW SAN volume from NetWare

I have am just about done migrating my GroupWise 8.0.3 systems from NetWare to OES Linux and have saved my largest PO for last. This is the only PO using a SAN volume. My plan is to just move the volume from the NetWare box the my new Linux (OES) server.
To test this process:
- I created a new SAN volume on my NetWare box and made a copy of the post office.
- I moved the volume to my new Linux server.
- I ran nssmu on the Linux box and did a F4 Refresh eDirectory for the pool and volume.
All good so far. The pool and volume are accessible. When I run a dbcopy -l /<path to postoffice> to convert to lower case I get the following:
[272] Failed to rename file /media/nss/RESTORE/ZOOPO.BAK/offiles/fd12/50FFFDB7.00G to /media/nss/RESTORE/ZOOPO.BAK/offiles/fd12/50fffdb7.00g Error=8201
If I try to manually rename one of the upper case files it also fails:
zoo-msg3:/media/nss/RESTORE/ZOOPO.BAK # mv WPHOST.DB wphost.db
mv: `WPHOST.DB and `wphost.db are the same file
So is it the case that you dont need to do a case conversion if the post office and/or domain are on NSS volumes?

MrSted <[email protected]> wrote:
> All good so far. The pool and volume are accessible. When I run a
> dbcopy -l /<path to postoffice> to convert to lower case I get the
> following:
>
In addition to what Massimo says about not really needing to rename the
files if you are on long namespace, the -l is a dangerous switch and
should rarely be used by a human.
http://www.caledonia.net/important-d...ercase-switch/
You actually ran it with the proper syntax. So you would not experience
data loss. But -l should be used with caution. And NEVER while the POA is
loaded. But it really should be run after the files are already the proper
case on the disk. Its real job is to make the guardian DB all lowercase and
only secondarily to attempt to rename files. I myself never use it to
attempt a file rename.
Personally I DO like to have the files all lowercase, even on NSS. You
never know when you need to pick up your data and stick it on a native
Linux volume. Search for chcase and there are a few windows utilities that
can do this for you. Just map a drive to the NSS volume. If you DO change
the case with a utility, then you can run the dbcopy -l but make sure the
POA is unloaded.
Danita - http://www.caledonia.net/register

How to Migrate 2 Netware SLP to OES 2SP3

I have two netware servers that are replica to my tree but not master replica and I like to migrate slp netware 6.5sp8 to oes 2 Sp3 linux. How do go about migrating slp?

Originally Posted by sl0000
Thanks for all the help. I appreciate very much.
Novell Documentation
section 13.5.3 may help as well
More or less you'll want to use:
net.slp.isDA = true
net.slp.useScopes = myScope1
net.slp.dasyncreg = true
slp.DAaddresses = IP_address_1,IP_address_2
(where "myScope1" can be your EXISTING SLPDA scope that you used for NetWare) and where the IP's will be your "new" servers (OES2) if replacing your NetWare DA, although it can also be a mix (ie, IP1 is the OES2 server and IP2 is your existing NetWare SLPDA).

Transfer Trustees from Netware to OES2 SP3

Hi everbody,
with the last metamig, I saw, that saved data from trustee.nlm should be restored.
I saved on the original Netware Server with trustee save /R daten: daten:daten.txt.
But I was not able to restore to my OES 2 SP3, I got a lot of error, ie. invalid token.
The Volume Name is the same as on Netware. All data have the same path.
Can anybody tell me the correct syntax how to restore the trustees to oes?
Thanks for helping,
Regards from Austria,
Reinhold

Originally Posted by rsteini
Hi everbody,
with the last metamig, I saw, that saved data from trustee.nlm should be restored.
I saved on the original Netware Server with trustee save /R daten: daten:daten.txt.
But I was not able to restore to my OES 2 SP3, I got a lot of error, ie. invalid token.
The Volume Name is the same as on Netware. All data have the same path.
Can anybody tell me the correct syntax how to restore the trustees to oes?
Thanks for helping,
Regards from Austria,
Reinhold
I don't believe (I could be wrong) that you can take the trustee.nlm and save the output in a format that OES Linux will understand (the OES LInux uses a .xml format which I think is different)
You could manually read through the file (that NetWare generates) and figure out if you wanted to manually reassign them
Or you could use the miggui (migration utility) on OES Linux to migrate the data (and trustees) from NetWare.

IPrint migration fails....

I tried to migrate some printers from NetWare 6.0 SP5 server to a OES2 in
diffrent
O's and OU's but within the same TREE.
I got loads of problems and diffrent error messages. Tried the command line
util "iprintmig"
as well as the X based "Migrate Novell iPrint" from Yast2.
Someone got problems migrating?

Originally Posted by gaclarks
I had some problems doing this in my test lab. One of the things I found was that you get an error if the printer driver defined for a printer is not available in the destination store. Having exactly the same drivers for all the printers to be migrated installed to the destination store fixed my problems in the lab. In the production system I have 300 printers with all kinds of drivers. So as a step prior to migration, I'm going to use the reporting tool to dump out all the printers and their drivers and clean it up so that I'm using the same driver for all printers of the same model (something I should do anyway) and then make sure they are installed to the new store prior to migration.
Me and a college (hpux-guy) rewritten the migrationscripts and now it works great! It uploads all drivers from netware-broker to the new oes2 driverstore,
recreates the printers in the new context and assign the same drivers to the
new printers. We solved it that way cuz Novell couldnt help us. (We cased it, and all they did was to reply with a URL to the documentation for creating a printer from iManager) muhahaha.. what a joke!

Iprint migration question

We had to back out of a migration last week because of issues with edir version on Netware. I've updated that and TSA, but another question just came up. I'm migrating iPrint from a cluster, plus doing transfer ID. If I choose cluster resource on the source server in miggui, I only get the consolidate option. Does that mean I need to first run a consolidation job just for iprint and then go back and run the transfer ID? Or will the consolidation screw up a transfer ID?

$(UService migrations based on cluster resources and Transfer ID are separated in Migration Tools (miggui). You need to execute Cluster based iPrint migration in one project and Transfer ID migration in another project.
Perform all service consolidation migrations and make sure they are all completed/synced and working before attempting Transfer ID.
>>>
From:
zenking<[email protected]>
To:
novell.support.open-enterprise-server.migration
Date:
07/22/2010 02:26 AM
Subject:
iprint migration question
We had to back out of a migration last week because of issues with edir
version on Netware. I've updated that and TSA, but another question just
came up. I'm migrating iPrint from a cluster, plus doing transfer ID.
If I choose cluster resource on the source server in miggui, I only get
the consolidate option. Does that mean I need to first run a
consolidation job just for iprint and then go back and run the transfer
ID? Or will the consolidation screw up a transfer ID?
zenking
zenking's Profile: http://forums.novell.com/member.php?userid=2813
View this thread: http://forums.novell.com/showthread.php?t=416302

Problems migrating from edir 8.7.3 to 8.8

Hi,
I need to do a hardware replace for a Netware 6.5 sp 8 server. This
server has edir 8.7.3.10. I loaded a new Proliant server with NW6.5 sp
8 to migrate to. The new server has edir 8.8 on it. The Migration
Wizzard guide says there can be problems migrating from NW6.5 from an
edir 8.7 to 8.8.
I tried to install the new server using the [INST: spedir] option
specifie in this article
(http://www.novell.com/communities/no...edirectory-873)
but the server keeps crashing.
Can I mirgate my old server edir 8.7.3 to the new one 8.8 using the
Migration Wizzard? If not is there any other way to force an install
of edir 8.7.3?
thanks

You could upgrade your eDir on the "original" server to 8.8
I've done that before without any problems.
(obviously this doesn't guarantee it will go right/well). Always have a complete backup of the .dib set (I use the dsrepair -rc on NetWare) as well as a "snapshot" of teh NetWare server if possible (ours is on the SAN, so I can clone the system disk before I do anything to it).

IPrint migration from Netware to OES 11.1...

Similar Messages

Maybe you are looking for