Hey @Bart! thanks for the post.
In researching, we have a few cases where if User Account Control is enabled, that User Account Control will significantly slow down the Plug-in's ability.
On one of these machines that has the plugin installed, please attempt to disabled UAC by setting this in the registry.
- Location: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System Key: EnableLUA Value: 0
You will need to reboot this machine.
Instead of disabling UAC you can also try running SQL Management Studio as an Administrator and accept the UAC prompt.
Please attempt the plugin afterwards, and let me know the speeds.
Hello Bart,
Yes, we are using SQL Management studio in our environment and DBAs handling the backup-restore operations.
Yes, it is comparatively slow (than java console) but not “extremely” slow.
Are you using SSO or local commvault account?
Hello Bart,
Yes, we are using SQL Management studio in our environment and DBAs handling the backup-restore operations.
Yes, it is comparatively slow (than java console) but not “extremely” slow.
Are you using SSO or local commvault account?
“local” commvault account.
Hey @Bart! thanks for the post.
In researching, we have a few cases where if User Account Control is enabled, that User Account Control will significantly slow down the Plug-in's ability.
On one of these machines that has the plugin installed, please attempt to disabled UAC by setting this in the registry.
- Location: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System Key: EnableLUA Value: 0
You will need to reboot this machine.
Instead of disabling UAC you can also try running SQL Management Studio as an Administrator and accept the UAC prompt.
Please attempt the plugin afterwards, and let me know the speeds.
Running SSMS as Administrator and that was indeed a lot faster.
Disabling UAC is of course a very difficult one. Isn’t there a root cause solution for this?
Hey @Bart! thanks for the post.
In researching, we have a few cases where if User Account Control is enabled, that User Account Control will significantly slow down the Plug-in's ability.
On one of these machines that has the plugin installed, please attempt to disabled UAC by setting this in the registry.
- Location: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System Key: EnableLUA Value: 0
You will need to reboot this machine.
Instead of disabling UAC you can also try running SQL Management Studio as an Administrator and accept the UAC prompt.
Please attempt the plugin afterwards, and let me know the speeds.
Running SSMS as Administrator and that was indeed a lot faster.
Disabling UAC is of course a very difficult one. Isn’t there a root cause solution for this?
Hi Bart,
When you right-click on a file or program and choose "Run as administrator," that process (and only that process) is started with an administrator token, thus providing high integrity clearance for features that may require the additional access to your Windows files (etc).
As you stated that the performance improved running the tool as administrator, this leads me to believe the latency could be caused by the user accounts permission to either our (CV) or Microsoft’s executables.
Reviewing the incident(s) that Mike referred to in his initial reply, I have checked and it was determined that after giving the specific user ‘read/write’ access to our installation directory, the delays were no longer seen.
By default 'users' are given read only access to the Commvault log files folder. Generally this is not an issue as the Commvault processes run as the local system account thus have access to read/write.
In the case of the SQL plug-in, some operations may be logged as the local user due to the involvement of a third party application (SSMS).
As per the SQL agents requirements - https://documentation.commvault.com/commvault/v11/article?p=18202.htm "Users who perform backup operations must be local administrators so that they have full control over the registry folder and the installation folder."
Rather than disabling UAC, you could try either giving the specific user or group of users who use this tool explicit read/write permissions to the Commvault installation folders or you could add these users to the local administrators group (if not already) as per the agents requirements and see if this helps alleviate the slowness being encountered.
In addition to this, when user access control is enabled and set to 'Always Notify' or 'Notify me only when apps try to make changes to my computer (default)’, it has proven to interfere with the execution of our processes - especially in instances where we are 'impersonating' user accounts to run operations or write to job results directories: https://documentation.commvault.com/commvault/v11/article?p=6595.htm
Could you please try either of the above and let me know if this helps?
@Chris Hollis That was the trick indeed. Perfect now!
tnx