Net stop system error 5 access denied
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
From SQL server 2012 I try to do this:
DECLARE @COMMAND nvarchar(4000)
SET @COMMAND = 'net stop <servicename>'
exec master.dbo.xp_cmdshell @COMMAND
I get system error 5 and Access denied as response
The service account (checked with whoami
) is added to the administrators, so what else can be wrong?
command-line sql-server-2012
add a comment |
From SQL server 2012 I try to do this:
DECLARE @COMMAND nvarchar(4000)
SET @COMMAND = 'net stop <servicename>'
exec master.dbo.xp_cmdshell @COMMAND
I get system error 5 and Access denied as response
The service account (checked with whoami
) is added to the administrators, so what else can be wrong?
command-line sql-server-2012
when you way 'From SQLServer 2012', do you mean from SQLServer Management Studio (ssms.exe) ?
– Frank Thomas
Aug 11 '17 at 15:31
Yes, if I put the command(s) in a .bat or .cmd and run that from the OS it's fine. When I try to run it from ssms I get the same error.
– Sjef
Aug 14 '17 at 13:29
run ssms as admin.
– Frank Thomas
Aug 14 '17 at 13:39
add a comment |
From SQL server 2012 I try to do this:
DECLARE @COMMAND nvarchar(4000)
SET @COMMAND = 'net stop <servicename>'
exec master.dbo.xp_cmdshell @COMMAND
I get system error 5 and Access denied as response
The service account (checked with whoami
) is added to the administrators, so what else can be wrong?
command-line sql-server-2012
From SQL server 2012 I try to do this:
DECLARE @COMMAND nvarchar(4000)
SET @COMMAND = 'net stop <servicename>'
exec master.dbo.xp_cmdshell @COMMAND
I get system error 5 and Access denied as response
The service account (checked with whoami
) is added to the administrators, so what else can be wrong?
command-line sql-server-2012
command-line sql-server-2012
edited Aug 11 '17 at 12:07
DavidPostill♦
108k27235271
108k27235271
asked Aug 11 '17 at 11:27
SjefSjef
62
62
when you way 'From SQLServer 2012', do you mean from SQLServer Management Studio (ssms.exe) ?
– Frank Thomas
Aug 11 '17 at 15:31
Yes, if I put the command(s) in a .bat or .cmd and run that from the OS it's fine. When I try to run it from ssms I get the same error.
– Sjef
Aug 14 '17 at 13:29
run ssms as admin.
– Frank Thomas
Aug 14 '17 at 13:39
add a comment |
when you way 'From SQLServer 2012', do you mean from SQLServer Management Studio (ssms.exe) ?
– Frank Thomas
Aug 11 '17 at 15:31
Yes, if I put the command(s) in a .bat or .cmd and run that from the OS it's fine. When I try to run it from ssms I get the same error.
– Sjef
Aug 14 '17 at 13:29
run ssms as admin.
– Frank Thomas
Aug 14 '17 at 13:39
when you way 'From SQLServer 2012', do you mean from SQLServer Management Studio (ssms.exe) ?
– Frank Thomas
Aug 11 '17 at 15:31
when you way 'From SQLServer 2012', do you mean from SQLServer Management Studio (ssms.exe) ?
– Frank Thomas
Aug 11 '17 at 15:31
Yes, if I put the command(s) in a .bat or .cmd and run that from the OS it's fine. When I try to run it from ssms I get the same error.
– Sjef
Aug 14 '17 at 13:29
Yes, if I put the command(s) in a .bat or .cmd and run that from the OS it's fine. When I try to run it from ssms I get the same error.
– Sjef
Aug 14 '17 at 13:29
run ssms as admin.
– Frank Thomas
Aug 14 '17 at 13:39
run ssms as admin.
– Frank Thomas
Aug 14 '17 at 13:39
add a comment |
2 Answers
2
active
oldest
votes
Run SQL Server 2012 as administrator, and the problem will go away.
The service account mentioned has administrator rights.
– Sjef
Aug 11 '17 at 13:52
Yes, but even so, the runtime has to be performed as administrator. You have to right-click the program, and choose run as administrator, to give the application extra rights. You can see the exact same behavior if you try to do the command in a command prompt window. Even if your user has admin rights, it will not work until you launch the command prompt as administrator. Its an UAC thing.
– LPChip
Aug 11 '17 at 14:25
In this case, the user running the DB service is unimportant to the issue. The issue is who can CONTROL the service, by starting/stopping/editing the service. SQL Injection attacks would be disastrous if just any old user could execute xp_cmdshell and by virtue of the SQLServers privileged access be able to run arbitrary commands as a server admin.
– Frank Thomas
Aug 11 '17 at 15:34
add a comment |
Allow non-sysadmin user to execute xp_cmdshell
from SSMS
I helped troubleshoot an issue where we needed to grant an app developer access to execute xp_cmdshell
from within an SSMS session rather than "Run as" from SQL Agent Job on a non-critical development server without making him a sysadmin on the SQL Server instance.
What We Did
Note: Domain user account can be replaced by work group account, local machine account, etc.
Important: You need to understand the risk of allowing users in your environment to execute OS level commands, and you should only grant this level of permissions to xp_cmdshell
to those which are trustworthy enough with this level of security with the proxy method.
Created a new domain user account with a strong password and took note of the username and password. Made sure the account was enabled and the password was set to never expire.
Created a new SQL Server Login tied to the new domain user account we created.
Created a new proxy credential tied to the domain user account.
EXEC sp_xp_cmdshell_proxy_account '<Domain><NewUser>', '<password>' -- you have to type actual password
Granted that SQL Server Login explicit
EXECUTE
access to the system extended stored proc from theMaster
DB namedsys.xp_cmdshell
.
--see who all has execute access to xp_cmdshell
Use master
EXEC sp_helprotect 'xp_cmdshell'
-- To allow advanced options to be changed.
EXEC sp_configure 'show advanced options', 1
RECONFIGURE
GO
-- Enable the xp_cmdshell procedure
EXEC sp_configure 'xp_cmdshell', 1
RECONFIGURE
GO
-- Grant execute permissions to account
GRANT EXECUTE ON xp_cmdshell TO [<Domain><NewUser>]
Grant the person the uses the
EXECUTE AS
impersonate permission to the new SQL Server Login.
GRANT IMPERSONATE ON LOGIN::[<Domain><NewUser>] TO [<Domain><UserGrantingExecuteAsUser>]
Now run the command with the EXECUTE AS LOGIN and pass the
net stop
command to thexp_cmdshell
stored procedure. The security principal as listed in step #5 above in the<Domain><UserGrantingExecuteAsUser>
should be that of the person you are running SSMS as security context wise for this task.
EXECUTE AS LOGIN = '<Domain><NewUser>'
DECLARE @COMMAND nvarchar(4000)
SET @COMMAND = 'net stop <servicename>'
EXEC xp_cmdshell @COMMAND
REVERT
Further Resources
- sp_xp_cmdshell_proxy_account
- CREATE USER (Transact-SQL)
- GRANT Server Principal Permissions (Transact-SQL)
- EXECUTE AS (Transact-SQL)
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1239888%2fnet-stop-service-system-error-5-access-denied%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Run SQL Server 2012 as administrator, and the problem will go away.
The service account mentioned has administrator rights.
– Sjef
Aug 11 '17 at 13:52
Yes, but even so, the runtime has to be performed as administrator. You have to right-click the program, and choose run as administrator, to give the application extra rights. You can see the exact same behavior if you try to do the command in a command prompt window. Even if your user has admin rights, it will not work until you launch the command prompt as administrator. Its an UAC thing.
– LPChip
Aug 11 '17 at 14:25
In this case, the user running the DB service is unimportant to the issue. The issue is who can CONTROL the service, by starting/stopping/editing the service. SQL Injection attacks would be disastrous if just any old user could execute xp_cmdshell and by virtue of the SQLServers privileged access be able to run arbitrary commands as a server admin.
– Frank Thomas
Aug 11 '17 at 15:34
add a comment |
Run SQL Server 2012 as administrator, and the problem will go away.
The service account mentioned has administrator rights.
– Sjef
Aug 11 '17 at 13:52
Yes, but even so, the runtime has to be performed as administrator. You have to right-click the program, and choose run as administrator, to give the application extra rights. You can see the exact same behavior if you try to do the command in a command prompt window. Even if your user has admin rights, it will not work until you launch the command prompt as administrator. Its an UAC thing.
– LPChip
Aug 11 '17 at 14:25
In this case, the user running the DB service is unimportant to the issue. The issue is who can CONTROL the service, by starting/stopping/editing the service. SQL Injection attacks would be disastrous if just any old user could execute xp_cmdshell and by virtue of the SQLServers privileged access be able to run arbitrary commands as a server admin.
– Frank Thomas
Aug 11 '17 at 15:34
add a comment |
Run SQL Server 2012 as administrator, and the problem will go away.
Run SQL Server 2012 as administrator, and the problem will go away.
answered Aug 11 '17 at 12:30
LPChipLPChip
36.8k55588
36.8k55588
The service account mentioned has administrator rights.
– Sjef
Aug 11 '17 at 13:52
Yes, but even so, the runtime has to be performed as administrator. You have to right-click the program, and choose run as administrator, to give the application extra rights. You can see the exact same behavior if you try to do the command in a command prompt window. Even if your user has admin rights, it will not work until you launch the command prompt as administrator. Its an UAC thing.
– LPChip
Aug 11 '17 at 14:25
In this case, the user running the DB service is unimportant to the issue. The issue is who can CONTROL the service, by starting/stopping/editing the service. SQL Injection attacks would be disastrous if just any old user could execute xp_cmdshell and by virtue of the SQLServers privileged access be able to run arbitrary commands as a server admin.
– Frank Thomas
Aug 11 '17 at 15:34
add a comment |
The service account mentioned has administrator rights.
– Sjef
Aug 11 '17 at 13:52
Yes, but even so, the runtime has to be performed as administrator. You have to right-click the program, and choose run as administrator, to give the application extra rights. You can see the exact same behavior if you try to do the command in a command prompt window. Even if your user has admin rights, it will not work until you launch the command prompt as administrator. Its an UAC thing.
– LPChip
Aug 11 '17 at 14:25
In this case, the user running the DB service is unimportant to the issue. The issue is who can CONTROL the service, by starting/stopping/editing the service. SQL Injection attacks would be disastrous if just any old user could execute xp_cmdshell and by virtue of the SQLServers privileged access be able to run arbitrary commands as a server admin.
– Frank Thomas
Aug 11 '17 at 15:34
The service account mentioned has administrator rights.
– Sjef
Aug 11 '17 at 13:52
The service account mentioned has administrator rights.
– Sjef
Aug 11 '17 at 13:52
Yes, but even so, the runtime has to be performed as administrator. You have to right-click the program, and choose run as administrator, to give the application extra rights. You can see the exact same behavior if you try to do the command in a command prompt window. Even if your user has admin rights, it will not work until you launch the command prompt as administrator. Its an UAC thing.
– LPChip
Aug 11 '17 at 14:25
Yes, but even so, the runtime has to be performed as administrator. You have to right-click the program, and choose run as administrator, to give the application extra rights. You can see the exact same behavior if you try to do the command in a command prompt window. Even if your user has admin rights, it will not work until you launch the command prompt as administrator. Its an UAC thing.
– LPChip
Aug 11 '17 at 14:25
In this case, the user running the DB service is unimportant to the issue. The issue is who can CONTROL the service, by starting/stopping/editing the service. SQL Injection attacks would be disastrous if just any old user could execute xp_cmdshell and by virtue of the SQLServers privileged access be able to run arbitrary commands as a server admin.
– Frank Thomas
Aug 11 '17 at 15:34
In this case, the user running the DB service is unimportant to the issue. The issue is who can CONTROL the service, by starting/stopping/editing the service. SQL Injection attacks would be disastrous if just any old user could execute xp_cmdshell and by virtue of the SQLServers privileged access be able to run arbitrary commands as a server admin.
– Frank Thomas
Aug 11 '17 at 15:34
add a comment |
Allow non-sysadmin user to execute xp_cmdshell
from SSMS
I helped troubleshoot an issue where we needed to grant an app developer access to execute xp_cmdshell
from within an SSMS session rather than "Run as" from SQL Agent Job on a non-critical development server without making him a sysadmin on the SQL Server instance.
What We Did
Note: Domain user account can be replaced by work group account, local machine account, etc.
Important: You need to understand the risk of allowing users in your environment to execute OS level commands, and you should only grant this level of permissions to xp_cmdshell
to those which are trustworthy enough with this level of security with the proxy method.
Created a new domain user account with a strong password and took note of the username and password. Made sure the account was enabled and the password was set to never expire.
Created a new SQL Server Login tied to the new domain user account we created.
Created a new proxy credential tied to the domain user account.
EXEC sp_xp_cmdshell_proxy_account '<Domain><NewUser>', '<password>' -- you have to type actual password
Granted that SQL Server Login explicit
EXECUTE
access to the system extended stored proc from theMaster
DB namedsys.xp_cmdshell
.
--see who all has execute access to xp_cmdshell
Use master
EXEC sp_helprotect 'xp_cmdshell'
-- To allow advanced options to be changed.
EXEC sp_configure 'show advanced options', 1
RECONFIGURE
GO
-- Enable the xp_cmdshell procedure
EXEC sp_configure 'xp_cmdshell', 1
RECONFIGURE
GO
-- Grant execute permissions to account
GRANT EXECUTE ON xp_cmdshell TO [<Domain><NewUser>]
Grant the person the uses the
EXECUTE AS
impersonate permission to the new SQL Server Login.
GRANT IMPERSONATE ON LOGIN::[<Domain><NewUser>] TO [<Domain><UserGrantingExecuteAsUser>]
Now run the command with the EXECUTE AS LOGIN and pass the
net stop
command to thexp_cmdshell
stored procedure. The security principal as listed in step #5 above in the<Domain><UserGrantingExecuteAsUser>
should be that of the person you are running SSMS as security context wise for this task.
EXECUTE AS LOGIN = '<Domain><NewUser>'
DECLARE @COMMAND nvarchar(4000)
SET @COMMAND = 'net stop <servicename>'
EXEC xp_cmdshell @COMMAND
REVERT
Further Resources
- sp_xp_cmdshell_proxy_account
- CREATE USER (Transact-SQL)
- GRANT Server Principal Permissions (Transact-SQL)
- EXECUTE AS (Transact-SQL)
add a comment |
Allow non-sysadmin user to execute xp_cmdshell
from SSMS
I helped troubleshoot an issue where we needed to grant an app developer access to execute xp_cmdshell
from within an SSMS session rather than "Run as" from SQL Agent Job on a non-critical development server without making him a sysadmin on the SQL Server instance.
What We Did
Note: Domain user account can be replaced by work group account, local machine account, etc.
Important: You need to understand the risk of allowing users in your environment to execute OS level commands, and you should only grant this level of permissions to xp_cmdshell
to those which are trustworthy enough with this level of security with the proxy method.
Created a new domain user account with a strong password and took note of the username and password. Made sure the account was enabled and the password was set to never expire.
Created a new SQL Server Login tied to the new domain user account we created.
Created a new proxy credential tied to the domain user account.
EXEC sp_xp_cmdshell_proxy_account '<Domain><NewUser>', '<password>' -- you have to type actual password
Granted that SQL Server Login explicit
EXECUTE
access to the system extended stored proc from theMaster
DB namedsys.xp_cmdshell
.
--see who all has execute access to xp_cmdshell
Use master
EXEC sp_helprotect 'xp_cmdshell'
-- To allow advanced options to be changed.
EXEC sp_configure 'show advanced options', 1
RECONFIGURE
GO
-- Enable the xp_cmdshell procedure
EXEC sp_configure 'xp_cmdshell', 1
RECONFIGURE
GO
-- Grant execute permissions to account
GRANT EXECUTE ON xp_cmdshell TO [<Domain><NewUser>]
Grant the person the uses the
EXECUTE AS
impersonate permission to the new SQL Server Login.
GRANT IMPERSONATE ON LOGIN::[<Domain><NewUser>] TO [<Domain><UserGrantingExecuteAsUser>]
Now run the command with the EXECUTE AS LOGIN and pass the
net stop
command to thexp_cmdshell
stored procedure. The security principal as listed in step #5 above in the<Domain><UserGrantingExecuteAsUser>
should be that of the person you are running SSMS as security context wise for this task.
EXECUTE AS LOGIN = '<Domain><NewUser>'
DECLARE @COMMAND nvarchar(4000)
SET @COMMAND = 'net stop <servicename>'
EXEC xp_cmdshell @COMMAND
REVERT
Further Resources
- sp_xp_cmdshell_proxy_account
- CREATE USER (Transact-SQL)
- GRANT Server Principal Permissions (Transact-SQL)
- EXECUTE AS (Transact-SQL)
add a comment |
Allow non-sysadmin user to execute xp_cmdshell
from SSMS
I helped troubleshoot an issue where we needed to grant an app developer access to execute xp_cmdshell
from within an SSMS session rather than "Run as" from SQL Agent Job on a non-critical development server without making him a sysadmin on the SQL Server instance.
What We Did
Note: Domain user account can be replaced by work group account, local machine account, etc.
Important: You need to understand the risk of allowing users in your environment to execute OS level commands, and you should only grant this level of permissions to xp_cmdshell
to those which are trustworthy enough with this level of security with the proxy method.
Created a new domain user account with a strong password and took note of the username and password. Made sure the account was enabled and the password was set to never expire.
Created a new SQL Server Login tied to the new domain user account we created.
Created a new proxy credential tied to the domain user account.
EXEC sp_xp_cmdshell_proxy_account '<Domain><NewUser>', '<password>' -- you have to type actual password
Granted that SQL Server Login explicit
EXECUTE
access to the system extended stored proc from theMaster
DB namedsys.xp_cmdshell
.
--see who all has execute access to xp_cmdshell
Use master
EXEC sp_helprotect 'xp_cmdshell'
-- To allow advanced options to be changed.
EXEC sp_configure 'show advanced options', 1
RECONFIGURE
GO
-- Enable the xp_cmdshell procedure
EXEC sp_configure 'xp_cmdshell', 1
RECONFIGURE
GO
-- Grant execute permissions to account
GRANT EXECUTE ON xp_cmdshell TO [<Domain><NewUser>]
Grant the person the uses the
EXECUTE AS
impersonate permission to the new SQL Server Login.
GRANT IMPERSONATE ON LOGIN::[<Domain><NewUser>] TO [<Domain><UserGrantingExecuteAsUser>]
Now run the command with the EXECUTE AS LOGIN and pass the
net stop
command to thexp_cmdshell
stored procedure. The security principal as listed in step #5 above in the<Domain><UserGrantingExecuteAsUser>
should be that of the person you are running SSMS as security context wise for this task.
EXECUTE AS LOGIN = '<Domain><NewUser>'
DECLARE @COMMAND nvarchar(4000)
SET @COMMAND = 'net stop <servicename>'
EXEC xp_cmdshell @COMMAND
REVERT
Further Resources
- sp_xp_cmdshell_proxy_account
- CREATE USER (Transact-SQL)
- GRANT Server Principal Permissions (Transact-SQL)
- EXECUTE AS (Transact-SQL)
Allow non-sysadmin user to execute xp_cmdshell
from SSMS
I helped troubleshoot an issue where we needed to grant an app developer access to execute xp_cmdshell
from within an SSMS session rather than "Run as" from SQL Agent Job on a non-critical development server without making him a sysadmin on the SQL Server instance.
What We Did
Note: Domain user account can be replaced by work group account, local machine account, etc.
Important: You need to understand the risk of allowing users in your environment to execute OS level commands, and you should only grant this level of permissions to xp_cmdshell
to those which are trustworthy enough with this level of security with the proxy method.
Created a new domain user account with a strong password and took note of the username and password. Made sure the account was enabled and the password was set to never expire.
Created a new SQL Server Login tied to the new domain user account we created.
Created a new proxy credential tied to the domain user account.
EXEC sp_xp_cmdshell_proxy_account '<Domain><NewUser>', '<password>' -- you have to type actual password
Granted that SQL Server Login explicit
EXECUTE
access to the system extended stored proc from theMaster
DB namedsys.xp_cmdshell
.
--see who all has execute access to xp_cmdshell
Use master
EXEC sp_helprotect 'xp_cmdshell'
-- To allow advanced options to be changed.
EXEC sp_configure 'show advanced options', 1
RECONFIGURE
GO
-- Enable the xp_cmdshell procedure
EXEC sp_configure 'xp_cmdshell', 1
RECONFIGURE
GO
-- Grant execute permissions to account
GRANT EXECUTE ON xp_cmdshell TO [<Domain><NewUser>]
Grant the person the uses the
EXECUTE AS
impersonate permission to the new SQL Server Login.
GRANT IMPERSONATE ON LOGIN::[<Domain><NewUser>] TO [<Domain><UserGrantingExecuteAsUser>]
Now run the command with the EXECUTE AS LOGIN and pass the
net stop
command to thexp_cmdshell
stored procedure. The security principal as listed in step #5 above in the<Domain><UserGrantingExecuteAsUser>
should be that of the person you are running SSMS as security context wise for this task.
EXECUTE AS LOGIN = '<Domain><NewUser>'
DECLARE @COMMAND nvarchar(4000)
SET @COMMAND = 'net stop <servicename>'
EXEC xp_cmdshell @COMMAND
REVERT
Further Resources
- sp_xp_cmdshell_proxy_account
- CREATE USER (Transact-SQL)
- GRANT Server Principal Permissions (Transact-SQL)
- EXECUTE AS (Transact-SQL)
edited Aug 21 '17 at 22:30
answered Aug 21 '17 at 18:07
Pimp Juice ITPimp Juice IT
25.4k114178
25.4k114178
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1239888%2fnet-stop-service-system-error-5-access-denied%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
when you way 'From SQLServer 2012', do you mean from SQLServer Management Studio (ssms.exe) ?
– Frank Thomas
Aug 11 '17 at 15:31
Yes, if I put the command(s) in a .bat or .cmd and run that from the OS it's fine. When I try to run it from ssms I get the same error.
– Sjef
Aug 14 '17 at 13:29
run ssms as admin.
– Frank Thomas
Aug 14 '17 at 13:39