Greetings
Yesterday I configured SureBackup together with a service provider and we tested a few scenarios. Of course we played around with a DomainController of all things.
Why a DC of all things? Somehow they don't seem to give correct feedback for heartbeat etc., so you can safely switch off the function and rely purely on the set waiting time before the roles are checked. Our workaround was to restart the VM that was started up in the lab and the second response generated was then sufficient for our Sure Backup job to continue.
But as it turned out, the tests to be executed for a domain controller seem to run with VBS Script. The only problem is that this is prevented by our group policies. Even Powershell only works with self-signed scripts. So before I reinvent the wheel here, I'd like to ask if anyone else with a similar setup has had the same problem?
Basically, I would have to either implement the ready-made VBS scripts via Powershell - or reverse the registry entry or group policy after starting the VM within the lab so that VBS works.
-
- Enthusiast
- Posts: 59
- Liked: 5 times
- Joined: Feb 01, 2022 10:57 am
- Full Name: David Springer
- Contact:
-
- Enthusiast
- Posts: 59
- Liked: 5 times
- Joined: Feb 01, 2022 10:57 am
- Full Name: David Springer
- Contact:
Re: Forbidden VBS with SureBackup
Sorry I will have to correct myself. Our DC Test was fine - the error occured during a test for SQL.
On the job you only see: "Error: Application group failed to start"
Inside the Logfile we could find: "[SureBackup] [S-BRE-SQL01] [ScriptTests] [Console] CScript error: Access to Windows Script Host has been disabled for this computer. Contact your administrator for further details."
On the job you only see: "Error: Application group failed to start"
Inside the Logfile we could find: "[SureBackup] [S-BRE-SQL01] [ScriptTests] [Console] CScript error: Access to Windows Script Host has been disabled for this computer. Contact your administrator for further details."
-
- Veeam Software
- Posts: 2359
- Liked: 558 times
- Joined: Jun 28, 2016 12:12 pm
- Contact:
Re: Forbidden VBS with SureBackup
Hi David,
Situation is clear, but I don't think you need to enable it on the GuestOSes as the script should run from the VBR server and connect to the GuestOS in the Virtual Lab/poke some ports on the Guest in the lab.
if you set the Enabled registry value under “HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Script Host\Settings”, doesn't it work? Regrettably a quick search doesn't show if there is a value to allow only approved scripts or not as this registry key doesn't seem well documented, but I think you only need to do this on the VBR server, which should simplify this a lot.
If it works, consider this, else I do think that just recreating it in powershell should be pretty fast and then you can sign it and run it. The pre-made scripts are nice but they aren't doing anything super special, and if you're remaking it in Powershell anyways, you can add/remove tests as you desire.
Situation is clear, but I don't think you need to enable it on the GuestOSes as the script should run from the VBR server and connect to the GuestOS in the Virtual Lab/poke some ports on the Guest in the lab.
Application test. Veeam Backup & Replication waits for applications inside the machine to start and runs a script against these applications. Veeam Backup & Replication uses two types of predefined scripts:
For DNS servers, domain controllers, Global Catalog servers, mail servers and web servers, Veeam Backup & Replication uses a script that probes an application-specific port. For example, to verify a domain controller, Veeam Backup & Replication probes port 389 for a response. If the response is received, the test is passed.
if you set the Enabled registry value under “HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Script Host\Settings”, doesn't it work? Regrettably a quick search doesn't show if there is a value to allow only approved scripts or not as this registry key doesn't seem well documented, but I think you only need to do this on the VBR server, which should simplify this a lot.
If it works, consider this, else I do think that just recreating it in powershell should be pretty fast and then you can sign it and run it. The pre-made scripts are nice but they aren't doing anything super special, and if you're remaking it in Powershell anyways, you can add/remove tests as you desire.
David Domask | Product Management: Principal Analyst
Who is online
Users browsing this forum: Amazon [Bot], Dynamic, Stabz, Zedification and 97 guests