cancel
Showing results for 
Search instead for 
Did you mean: 

wsl_account AD account problem on NBU 8.0 installation on Windows 2012 R2

Michael_G_Ander
Level 6
Certified

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.

The standard questions: Have you checked: 1) What has changed. 2) The manual 3) If there are any tech notes or VOX posts regarding the issue
1 ACCEPTED SOLUTION

Accepted Solutions

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. 

The standard questions: Have you checked: 1) What has changed. 2) The manual 3) If there are any tech notes or VOX posts regarding the issue

View solution in original post

18 REPLIES 18

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

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.

 

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.

 

 

The standard questions: Have you checked: 1) What has changed. 2) The manual 3) If there are any tech notes or VOX posts regarding the issue

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

 

The standard questions: Have you checked: 1) What has changed. 2) The manual 3) If there are any tech notes or VOX posts regarding the issue

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.

The standard questions: Have you checked: 1) What has changed. 2) The manual 3) If there are any tech notes or VOX posts regarding the issue

tunix2k
Level 5
Partner Accredited

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

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.

The standard questions: Have you checked: 1) What has changed. 2) The manual 3) If there are any tech notes or VOX posts regarding the issue

tunix2k
Level 5
Partner Accredited

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

quebek
Moderator
Moderator
   VIP    Certified

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

quebek
Moderator
Moderator
   VIP    Certified

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

 

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.

 

The standard questions: Have you checked: 1) What has changed. 2) The manual 3) If there are any tech notes or VOX posts regarding the issue

quebek
Moderator
Moderator
   VIP    Certified

Yes I did use the local user/group.... Just shared the information that with GPO managing the local security this was failing...

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.

 

 

 

The standard questions: Have you checked: 1) What has changed. 2) The manual 3) If there are any tech notes or VOX posts regarding the issue

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.

The standard questions: Have you checked: 1) What has changed. 2) The manual 3) If there are any tech notes or VOX posts regarding the issue

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. 

The standard questions: Have you checked: 1) What has changed. 2) The manual 3) If there are any tech notes or VOX posts regarding the issue

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

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.

The standard questions: Have you checked: 1) What has changed. 2) The manual 3) If there are any tech notes or VOX posts regarding the issue

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.


Seems that we might still hit some bumps with 8.0, have not gotten around to test more than installation due to other work.

The standard questions: Have you checked: 1) What has changed. 2) The manual 3) If there are any tech notes or VOX posts regarding the issue