Data Protector 8.10: With Data Protector 8.10 it is very important to check name resolution before starting the installation. If it’s not possible to resolve the FQDN of the cell server (of course short and revers too), a login prompt will appear when opening the GUI (this is the LDAP logon dialog, which is an additional feature in DP 8.10) and a “permission denied” message afterwards. In documentation it is listed that a working name resolution is a requirement for DP 8.10. If the installation was done without working name resolution for the cell server, a new installation has to be done after name resolution was fixed; a newly generated certificate was not accepted by the GUI. Additional information: With DP 8.10 certificates are used locally to access the GUI, you will be prompted to accept the certificate when launching the GUI for the first time after the installation. In case your system name is different from the name in the certificate the local logon will fail as TLS will work with FQDN only.
Update: If the Cell Server is installed on a German or Non-English Linux system, the generated certificate might be wrong or will not be generated. This happens as the return values are expected to be in English, which is not true when locale is not set to English”. As a Workaround set locale to i.e. ‘en_gb-UTF-8’ before starting the migration.
Update: If the Cell Server is installed in a cluster environment, the certificate might be issued for the physical host, instead of virtual name. With the Perl program omnigencert.pl it is possible to generate a certificate using the virtual name of the cluster. For more details refer to help and search for ‘To generate CA, client, and server certificates in the SG-CLUSTER environment’.
Data Protector 8.00: When using Granular Recovery Extension for Microsoft Exchange you may receive a “User does not have required roles” message. In this case the “Mailbox Import Export” role needs to be assigned directly to the GRE user. More details can be found here: http://support.openview.hp.com/selfsolve/document/KM00482317 (HP Passport Account required).
My GUI is asking for a username/logon. I can nslookup the CM FQDM, shortname, and IP address. I can do the same from the CM to my PC. I have uninstalled and reinstalled the GUI and re-accepted a new certificate from the CM but it still asks for a name. ideas? I am un HP-UX 11.31. My Windows system is v 7.
Hi Vince,
does complete name resolution work for your client too?
Best regards
Daniel
This what you mean? From my client to the server:
C:\Users\vlaure>nslookup
Default Server: s927-dcstl1.ds.ad.ssmhc.com
Address: 165.104.76.130
> sapbck.ssmhc.com
Server: s927-dcstl1.ds.ad.ssmhc.com
Address: 165.104.76.130
Name: sapbck.ssmhc.com
Address: 165.104.137.39
> sapbck
Server: s927-dcstl1.ds.ad.ssmhc.com
Address: 165.104.76.130
Name: sapbck.ssmhc.com
Address: 165.104.137.39
> 165.104.137.39
Server: s927-dcstl1.ds.ad.ssmhc.com
Address: 165.104.76.130
> 165.104.137.39
Server: s927-dcstl1.ds.ad.ssmhc.com
Address: 165.104.76.130
Name: sapbck.ssmhc.com
Address: 165.104.137.39
BTW, I think I got past the username/password by adding the DPWINBDL_00813 patch to my work station. Now I am getting an SSL 7116 error. And yes, I have regenerated a credential.
perl omnigencert.pl -server_id FQDN -server_san ip:1.2.3.4 -user_id hpdp -store_password PASSWORD
thanks for toy reply…
After finally getting higher up in the HP food chain for help an engineer discovered ONE string that was wrong in the database. He had me export it, change it, reimport it. All is happy.
Would LOVE to get that kind of support each time!
Thanks for all your replies too!
Hi Vince,
can you please share what was done?
Best regards
Daniel
There was an incorrect value in the database. So the engineer had me export the database and change the value to a new one.
1. Stop omniback (omnisv -stop)
2, Save a copy of /var/opt/omni/server to another place
3. start omniback (omnisv -start)
4. Change it to maintence mode (omnisv -maintenance 1)
5. Wait the 300 seconds then export the database (omnidbutil -writedb /spacewhereIcanputit)
6. Change the incorrect value to the default. cat dpidb.dat | sed ‘/s/badvalue/newvalue/’ > temp.idb
7. rm dpidb.dat ; mv temp.idb dpidb.dat
8. reimport the database and say yes to overwrite (omnidbutil -readdb /spacewhereIcanputit)
9. Exit maint mode (omnisv -maintenance -stop)
The issue that makes this solution unique it the corrupt value that needed to be replaced.
Hope this helps someone though.