I might have found a minor bug in the backup job configuration that only occurs under specific circumstances. I don't know if it already existed in previous versions but we're currently running v9.5 Update 1.
We have a backup Job that is configured to back up all VMs on our VMware 6 Cluster that are not already backed up by other jobs. So the job objects are the whole cluster (included) and the excluded VMs that are already backed up. When we initially set up the job we configured the File System Indexing feature for the whole cluster (with default settings) and also added our WSUS VM as an exception to exclude the WSUS store directory from indexing. Some time later we disabled the whole File System Indexing feature for this job because we figured that we actually don't need indexing for those VMs.
BUT since then whenever we test the credentials for this job (Edit job -> Guest Processing -> Test Now) the test fails for the WSUS VM with "Credentials are not specified" although the WSUS VM should inherit the credentials from the default credentials setting of the job/cluster. The strange thing is that when we explicitly add the WSUS VM (Edit job -> Guest Processing -> Credentials) and configure it to use exactly the same credentials that are used as default for the job (in "domain\user" format, not "Default") the test succeeds.
After investigating the job and its job objects using Veeam PowerShell ("$job | get-vbrjobobject | fl") we found that despite the File System Indexing feature being disabled for the job (and thus all the settings in this section should be ineffective) there still is a job object for the WSUS VM with Type "GuestFSIndexingChild" and with NO WinCredsID in its VssOptions.
So we re-enabled File System Indexing, removed the exception for the WSUS VM, disabled File System Indexing again and started the credentials test. And guess what ... the test for the WSUS VM used the default credentials of the job and succeeded. Also in PowerShell the job object for the WSUS VM was gone. So it seems that despite File System Indexing being disabled there are still some parts of the Indexing configuration that remain active and affect other parts of the job configuration.
Even though in our case this was a minor inconvenience that could easily be worked around and eventually solved I wanted to share this with you because it might affect other parts of the backup job configuration and cause problems that we didn't run into (yet).
-
- Influencer
- Posts: 17
- Liked: never
- Joined: Nov 21, 2016 1:27 pm
- Full Name: Florian Guenzel
- Contact:
-
- Veteran
- Posts: 361
- Liked: 109 times
- Joined: Dec 28, 2012 5:20 pm
- Full Name: Guido Meijers
- Contact:
Re: Probable minor bug in back job configuration
DId you at any time re-add the WSUS VM to the Exceptions? Maybe it got reconfigured (or restored/reinstalled) at some time and Veeam detected it as a new Vm with the same name thus not recognizing the Vm as the one you setup in the exceptions. Happened to us some time ago...
-
- Influencer
- Posts: 17
- Liked: never
- Joined: Nov 21, 2016 1:27 pm
- Full Name: Florian Guenzel
- Contact:
Re: Probable minor bug in back job configuration
No, the VM was part of the initial list of VMs that were configured for this job. At first the default indexing settings were active for the whole Cluster and we then added the WSUS VM to the exception list to prevent the WSUS store directory from being indexed. After that there were no changes to the VMs backup config until we completely disabled indexing for the whole job.
-
- Veeam Software
- Posts: 21139
- Liked: 2141 times
- Joined: Jul 11, 2011 10:22 am
- Full Name: Alexander Fogelson
- Contact:
Re: Probable minor bug in back job configuration
Hi Florian, thanks for the heads up, we will try to reproduce the behavior you're describing.
-
- Veeam Software
- Posts: 649
- Liked: 170 times
- Joined: Dec 10, 2012 8:44 am
- Full Name: Nikita Efes
- Contact:
Re: Probable minor bug in back job configuration
Thank you, confirmed as a bug and submitted to our bug tracking system.
As we see, no system problems, only credential test fails.
As we see, no system problems, only credential test fails.
Who is online
Users browsing this forum: scrat and 75 guests