Follow the procedures for export / import [https://gluu.org/docs/deployment/upgrading/](https://gluu.org/docs/deployment/upgrading/)

Hi, Yoom Could you confirm that this: > Now I need to migrate the user's data from the old GLUU version 2.1 to the new version GLUU 2.4.4 ...is correct? Your old Gluu instance if of version **2.1**? That's pretty old one, we may not have a solid upgrade recommendations for such old instance. Unless you meant 2.4.1, of course. > How to export only the user data separately from the server configuration? Do you mean to export user entries from Gluu's internal LDAP directory? I take it you don't use Cache Refresh to pull them from some backend directory, and create them directly inside the Gluu's own directory, right? Those entries are stored below `ou=people,o=@!YOUR.ORG.INUM,o=gluu` branch, where `YOUR.ORG.INUM` is unique number generated during installation. To find out what the full DN you may run search like that (inside the container): `# /opt/opendj/bin/ldapsearch -h 127.0.0.1 -p 1636 -s sub -T -Z -X -D 'cn=directory manager' -w 'YOUR_LDAP_PASS' -b 'o=gluu' '(ou=people)'` `YOUR_LDAP_PASS` is by default the same as password of the default admin account you used to log in to web UI right after installation. After you've dumped all user entries under that branch (make sure you exclude their sub-entries representing grants and sessions, use `objectclass=` filter clauses to narrow search's range down) with `ldapsearch`, you can import them with `ldapmodify` under the corresponding branch of your new instance. Some schema conflicts are possible, if those entries are using custom attributes, or your old instance is too outdated, you may need to update objectclassess of them accordingly.

2.1 ...is correct? Yes. We were one of the earlier tester of your product. Thanks for the information. I will give it and try. Yoom

Here is what it shown. ./ldapsearch -h 127.0.0.1 -p 1636 -s sub -T -Z -X -D "cn=directory manager" -w "password" -b "o=gluu" "ou=people" dn: ou=people,o=@!C032.AAAA.2FA5.CCCC!0001!BCB6.BBB,o=gluu ou: people objectClass: organizationalunit objectClass: top What will be the correct ldap export and search string to export user entries from Gluu's internal LDAP directory? Thanks, Yoom

The following search will give me the information. Is this the right syntax to query only the user information? if so I am assuming the for the export I would just replace the ldapsearch with the export right? ./ldapsearch -h 127.0.0.1 -p 1636 -s sub -T -Z -X -D "cn=directory manager" -w "password" -b "o=gluu" "objectClass=gluuPerson" What about user's inum ?? would the new system work with the inum from the old version 2.1?

Hi, Yoom. 1. You also could first narrow down your scope by searching for **"ou=people"**, then using its DN with `-b` argument in your final search, thus ensuring no excessive entries will be caught in it 2. As entries you'll be importing will contain encoded passwords attributes, you need to adjust OpenDJ's password policy in your new instance before conducting it: `# dsconfig -p 4444 -h 127.0.0.1 -D 'cn=Directory Manager' -w 'YOUR_LDAP_PASS' set-password-policy-prop --policy-name "Default Password Policy" --set allow-pre-encoded-passwords:true -X -n` 3. Regarding what tools to choose, I would recommend to stick to **ldapsearch/ldapmodify** for export/import, correspondingly, as other ones which names suggest you should use them instead actually gave me some troubles in past, depending on OpenDJ's version. You can try it either ways, though, seems like you'll need to experiment a bit anyway. For **ldapmodify**, there is a key "-a" or "--defaultAdd", which "treats records with no changetype as add operations" - will be helpful in your case as what **ldapsearch** will return to you won't be a correct ldif file for **ldapmodify** to process "as-is", but with this key you can simply feed it to the tool.

> What about user's inum ?? would the new system work with the inum from the old version 2.1? That's a hard question. Let's hope Michael will find some time to check on this ticket. The only idea I can provide at the moment - you could create a couple of users in your new instance, to get some impressions of inum's structure. You'll see that most of it won't be changing between user entries, only the last `XXXX.XXXX` part will be. So you could take the permanent base as it is, and then write some simple python script that will generate a required number of unique inums by varying that last part, and will update inums in the file containing output you'll get from **ldapsearch**. That's not ideal, of course, but coding full sequence of requesting new inums the right way would be even more cumbersome, as it will involve accessing UMA-protected endpoints of oxAuth. Another difficulty will be if you are using custom attributes for user entries in your old instance (perhaps `edu*` attributes too). They are added by including special **objectclass** which name is derived from `orginum`. You'll need to update it so it would start to correspond to name of the similar **objectclass** in the new instance.

...of course, you'll need to update DNs of all entries too before importing them. Unless you need each user to keep inum from before, this should work ok. Otherwise, it *may* require to also set orginum of the new instance to the orginum of previous one (not completely sure, that's where Michael's knowledge would be very helpful). That may be troublesome by itself, but probably can be done with editing `setup.properties.last` and using automated installation mode.

Hi Samuseu, I am having a little difficulty following your suggestion below. <<You also could first narrow down your scope by searching for "ou=people", then using its DN with -b argument in your final search, thus ensuring no excessive entries will be caught in it This is what I ran. ./ldapsearch -h 127.0.0.1 -p 1636 -s sub -T -Z -X -D "cn=directory manager" -w "Mach1ne1" -b "o=gluu" "ou=people" "objectClass=gluuPerson" This is what I get back for the dn: ou=people,o=@!C032.849B.2FA5.5E8C!0001!BCB6.4A42,o=gluu What should I be including in my ldapsearch string so I will get what you had suggested? Thanks, Yoom

Just use `ou=people,o=@!C032.849B.2FA5.5E8C!0001!BCB6.4A42,o=gluu` in `-b` instead of **"o=gluu"**, this will narrow down search scope to sub-tree with user entries in it. You can check documentation for `ldapsearch/modify`, if you unsure what different keys mean and how the tool works, actually, you should to, seems like that task won't be easy.

Hi, Yoom. FIY, Michael shared an idea that may help in your case yesterday. You could try to configure Cache Refresh feature in your new instance and point it out to your old instance's internal LDAP directory (may require some port opening/forwarding). Set it to request all user attributes you care to migrate, set mappings for them telling what imported attribute will correspond to what attribute of the new instance. You can also create CR script to modify values on the fly, if you need. You'll be able to set scope we talked about and apply any custom search filters you need in CR's properties. The main benefit of this approach is that you won't need to generate inums by yourself, and export/import users manually, CR will do all this automagically, if configured right. One possible downside is that it's not clear whether CR will be able to handle pre-encoded user passwords which user entries in you old instance contain, I suppose. Above I mentioned how to allow preencoded password import in your new instance, but no idea whether it will help in this case. Still worth a try. Another possible problem is import of binary attributes, if you have some. In any case, you can always exclude passwords from CR's list, and write a separate Python script afterwards which will iterate through all user entries in you old instance, getting their passwords, and will add them to corresponding entry of the new instance via LDAP. Still it's better approach, there is no need to care about inums and such this way.

Thank you very much for your and Michael's suggestion. I will give it a try. Thanks, Yoom