02-14-2017 04:58 AM
I have run into a problem with the wsl_account when trying to install NBU 8.0
I keep getting that the domain cannot be resolved to a domain controller.
Which is strange as I have no problem doing a nslookup of the domain or logon to it from the same machine.
Have checked that I use the USERDOMAIN as per http://www.veritas.com/docs/000125383 and that password for the wsl_account user is correct
Have also created a support case on this problem.
Solved! Go to Solution.
08-21-2017 04:37 AM
In the latest update (New Netbackup.msi) only the 20 character limit is still there.
I am told that the findings will be put into the 8.1 installer and in the 81350 technote, which hopefully will get an Active Directory user section.
So I will set this as solved.
02-14-2017 05:23 AM
My understanding is that you need to create a local user called nbwebsvc and local group nbwebgrp as per http://www.veritas.com/docs/000081350
If my understanding is incorrect, please let us know what Support says.
02-14-2017 05:42 AM
Then it really does not make sense that you can choose an Active Directory account, if you have to create the account locally too.
Hope it is "just" something with secure environment we are running.
02-22-2017 01:09 AM - edited 02-22-2017 02:44 AM
Have managed to install Netbackup 8.0 using the NBPREINSTALL_CRITICAL_OVERRIDE YES option as described in http://www.veritas.com/docs/000020600 as suggested by the supporter
But is not a way I want to install Netbackup 8.0 in the production enviroments, so the case is still open.
EDIT: The NBPREINSTALL_CRITICAL_OVERRIDE YES option only functions when UAC is disabled it seems.
Starting to get the feeling that this 8.0 installer has not been properly tested
03-15-2017 03:23 AM - edited 03-15-2017 03:24 AM
No luck so far, would help a lot if Veritas could tell what the preinstall check actually did in regards to the web service account.
Has aksed for the support case to be escalated as we cannot have a program doing unknown things against our domain controllers.
03-15-2017 03:56 AM
Hi Michael !
Your problem makes me worry for future upgrades on customer side.
As far as I understood both accounttypes are available local and domain.
From the link @Marianne posted:
Note: In clustered environments, make sure local accounts are defined consistently on all cluster nodes. For UNIX platforms, the UID must be the same for each local account
which means for Windows OS:
Note: You must use domain accounts in clustered environments on Windows.
ciao
tunix2k
03-16-2017 06:16 AM
Yes in principle both local and domain account is available, but in practice it seems that using a domain account gives some challenges especially if you like us has secured our environment.
As I see it, the problem is with the way the preinstall check tries to communicate with the domain controller, as it seems to work when you ignore the preinstall check with the override environment variable.
03-23-2017 06:40 AM
Hi,
I have read http://www.veritas.com/docs/000125383 again and testet with Windows 2012R2 Domain and 2012R2 Masterserver.
I can confirm that the problem exists and the solution is to use the Domainname rather than the DomainDNSName.
In my example the DomainDNSname was local.domain and the Domainname NetBiosDomain.
The insatller is able to check the password for nbwebsvc@local.domain or for NetBiosDomain\nbwebsvc but with local.domain the problem occured.
Simply use the (netbios-) Domainname instead of the DNS Suffix and it works.
Do others made the same experience ?
ciao
tunix2k
04-11-2017 04:59 AM - edited 04-11-2017 05:01 AM
Hey
So on today (second attempt) I was running NBU upgrade from 772 to 80 on windows based OS. First attempt failed in similar way as the today's one. But on today I had larger window to troubleshoot this thing... Here is the excerpt from install log:
"04-11-2017,10:13:57 : Waiting for command: setupWmc.bat
04-11-2017,10:14:01 : Command produced the following output (will display up to 8192 characters):
04-11-2017,10:14:01 : -------------------------------------------------------------------------->
04-11-2017,10:14:01 : Unable to grant the log-on-as-service right to group "nbwebgrp". Please refer E:\Program Files\Veritas\NetBackup\wmc\WEBSERVER\logs\nbwmc_setupWmc.log for more details.
04-11-2017,10:14:01 : Failed to restore the original security policies. You may reattempt using this command:
04-11-2017,10:14:01 : secedit /configure /cfg "E:\Program Files\Veritas\NetBackup\wmc\bin\install\.\security_policy_config.db" /db "E:\Program Files\Veritas\NetBackup\wmc\bin\install\.\defltbase.sdb"
04-11-2017,10:14:01 : --------------------------------------------------------------------------<
04-11-2017,10:14:01 : Command returned status 4294967295.
+ 04-11-2017,10:14:01 : Configuration script setupWmc failed
04-11-2017,10:14:01 : CustomAction Deferred_WebAdminConsoleOps returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
+ 04-11-2017,10:14:01 : Action ended 10:14:01: InstallFinalize. Return value 3.
04-11-2017,10:14:01 : Action 10:14:01: Rollback. Rolling back action:"
I ended up with NBU which was not starting. nbdb_ping command was stating that cannot decrypt password. other command like vmoprcmd were not working as were complaining that some dlls are wrong or missing...
outcomes are as follow:
I have no clue why this install script is trying to grant to nbwebgrp logon as a service right... It is mentioned in below TN https://www.veritas.com/support/en_US/article.000081350 to only grant this right to nbwebsvc user - no one is stating about newly created group - nbwebgrp. At the end I even had in this logon as a service the user as well the group. I need to add that this security policy setting in my env are being managed by GPO - so all users, groups additions to above had to be routed via wintel team - pain in the back... So thay added this user and group there, I ran gpupdate /force, saw these two entries there in secpol.msc and still upgrade was failing ( I was told by VRTS support we can try this upgrade few times even if my NBU is in this wierd status). Wintel team member did propose to remove this backup server from the GPO for these security setting... which he did. Then I have locally added the nbwebsvc user to logon as a service - restarted (I think 7th time) NBU upgrade and it ended successfully. After the upgrade I checked this policy and there was as well the user and the group - so looks like the installer is not checking if group is there (there was one time it was there but still it was trying to grant this right to that group) and it is failing on this attempt as locally it was impossible to grant this right to any one as this is managed via GPO.
After all I find this one TN - which could have helped me if I was aware of it earlier https://www.veritas.com/support/en_US/article.000125106
04-11-2017 11:39 PM
Just to share with you mine findings...
I was recently upgradning windows based NBU 772 master server to 8. All prerequistes describe in this TN were made. Unfortunately upgrade failed... And it failed that NBDB was not up and running... Once I get it working - after copying DB files from staging directory, it turned out that not all binaries, dll were rolled back properly... So I ended up with the NBU uninstall and fresh installation followed by catalog recovery. That was firts attempt.
On second one attempt scenario was similar - but I had wider window to play with this environment. Installer failed on this step: "Unable to grant the log-on-as-service right to group "nbwebgrp". Please refer E:\Program Files\Veritas\NetBackup\wmc\WEBSERVER\logs\nbwmc_setupWmc.log for more details." I opened a case with VRTS support - thay did suggest this TN https://www.veritas.com/support/en_US/article.000125568
It did not help. So I asked my wintel team to grant the logon as a service the local group nbwebgrp. Again the upgrade failed - I was just starting yet another installation wizzard even though the NBU was in this strange state. Then I asked my wintel team to pull out this server from GPO which is managing these local security policies. I added than by using secpol.msc this user to logon as a service right... Started again the installer and this time it finished successfully.
So the outcome for me is like that - if GPO do manage the user rights assignmnets the upgrade is failing...
After upgrade wintel team put back this server to GPO and this WEB server service is running without any issues.
Also I found out this one being useful https://www.veritas.com/support/en_US/article.000125106
04-19-2017 03:53 AM
Seems we are stuck at the moment as the preinstall (nbcheck.exe) was compiled from Perl without including the debug/logging option. Have asked if we can get an nbcheck compiled with the debug option included as an EEB.
Have a suspicion that the domain controller is not either not found or passed properly to the user and group check functions.
@quebek let me guess, you used a local user and group right ? This works, but is not an option for us.
04-19-2017 04:55 AM
Yes I did use the local user/group.... Just shared the information that with GPO managing the local security this was failing...
06-14-2017 04:28 AM
Turns out some of the problem is that one of the perl moduls used in nbcheck is using tcp for ping where Windows uses imcp.
06-29-2017 05:31 AM
Findings so far:
not imcp for ping (solved in EEB nbcheck)
limit on user name and group name on 20 characters
Local domain group cannot be used only global works.
08-21-2017 04:37 AM
In the latest update (New Netbackup.msi) only the 20 character limit is still there.
I am told that the findings will be put into the 8.1 installer and in the 81350 technote, which hopefully will get an Active Directory user section.
So I will set this as solved.
08-25-2017 01:43 AM
Just going to add my findings for those who have run into problems with the WSL in NBU 8.0 as well:
- The issues with WSL are OS independent. We have had this issue with both 2008 R2 and windows 2012 R2 servers.
- Running nbcheck manually with the same parameters as the ones used during installation returns no error, the only time nbcheck fails when using a domain user instead of a local user is when it is used during installation.
- The only way to use WSL on a clustered environment is by using a domain user/group, so local user/group is not an option
- The only way to get around this issues is to use the NBPREINSTALL_CRITICAL_OVERRIDE YES option as described in http://www.veritas.com/docs/000020600
- There is a high probability that even though the installation finishes correctly, afterwards you will have issues with WSL. We had to add the WSL user/group to the local admin group on both nodes to keep it running stable.
- Make sure not to deviate from the standard naming for both group and user. For some reason we have had issues when using a different name for both and had to reconfigure WSL as per http://www.veritas.com/support/en_US/article.000116317.html
08-25-2017 03:53 AM
Most of the problems with the AD user account except the 20 character limit should be solved in the latest Netbackup.MSI that was made for us in case 22051390.
What kind of problems have you seen after the installation ? Curious as we generally does not grant administrator privilege and we will deviate from the nbwebsvc and nbwebgrp names.
08-25-2017 04:19 AM
Michael,
.msi for installation was the one that was downloaded from my.veritas portal. I cannot verify whether this is the latest .msi that was created for you in said case.
The issues we saw:
- folder with username under /var/global/Vxss/nbcertservice was generated with the standard username instead of the modified username that was used during installation.
- commands to inquire or generate certificates (nbcertcmd) were generating handshake issues or invalid answers
- After reconfigure, the service would boot and keep running but crash whenever the admin console was opened or any calls were passed to said service. This was resolved by adding the user/group to the local admins.
08-25-2017 05:19 AM
Seems that we might still hit some bumps with 8.0, have not gotten around to test more than installation due to other work.