I am attempting to automate the installation of SQL Server 2016 Express.
I have a chef cookbook to install SQL Server Express using the chocolatey package.
The same command as a chef resource
chocolatey_package 'sql-server-express' do
action :install
options '--cachelocation c:\temp\choco'
end
Equivalent PowerShell command
choco install sql-server-express --cachelocation c:\temp\choco
If I install SQL Server Express normally with the install wizard, I can authenticate and create / modify databases no problem.
If I install SQL Server Express with chocolatey / chef, I am not able to create or modify databases.
The error when trying to create a new database
CREATE DATABASE permission denied in database 'master'
The error when trying to modify an existing database
The server principal "Foo\Bar" is not able to access the database "foobar" under the current security context
I've tried logging in as the 'sa' user. mixed authentication is not enabled, and I can't enable it.
How can I get chocolatey installations of SQL Server Express users the same as a normal installation?
After many days I discovered the problem. Run chocolatey as a local administrative user, not SYSTEM.
Why:
The chocolatey package will not install if the command is executed over WinRM due to limitations of the WinRM protocol.
The common work around is to run chef/chocolatey in a scheduled task.
Unfortunately, scheduled tasks run as the SYSTEM user. The result is that MSSQL will only allow the SYSTEM user to run administrative commands.
The solution is to run chocolatey inside a scheduled task as a local system account (not SYSTEM). Or use RDP to log into the system and run the chocolatey command directly (not over winrm).
An example of how to run chef test kitchen as a (non SYSTEM) elevated user
transport:
name: winrm
elevated: true
elevated_username: vagrant
elevated_password: vagrant
Related
I have an installer that's running the SQL Server 2014 Express installer in unattended mode.
Basically, it's creating a command-line and running the setup.
My problem is that I need to be able to connect to the installed instance as admin using SQL Server authentication.
The command-line already contains /SECURITY MODE=SQL. I can create a SQL login and login successfully, so that part of the problem works fine.
My problem is that while I can see sa in sys.server_principals, it's flagged as is_disabled, and I can't login using it.
Is there a way, when running the SQL Server 2014 install unattended, to pass command line arguments that will have it enable sa so I can successfully login using it?
Or some other login, if that's easier.
What I need is a sql_login that I can use to connect to the database as an db administrator without regard for the permissions of the logged-in windows user, after having run the installer in unattended mode.
The full commandline args:
/QS /IACCEPTSQLSERVERLICENSETERMS /ACTION=Install /FEATURES=SQL
/INSTANCENAME=SQLEXPRESS /SAPWD="SQLSVCPASSWORD"
If I login to Windows using an admin account, I can connect to the database using Windows authentication. I can then create a normal SQL Server login. With that, I can then login using SQL Server authentication and that account.
So I'm certain the DB is in mixed mode. And this:
Exec xp_instance_regread N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'LoginMode'
returns '2'.
My problem is that I need the users to be able to run the software without being a windows admin. And part of what the software needs to be able to do is to drop and create databases, within the instance.
So I need SQL admin permissions, without depending upon the windows user having elevated permissions.
===
The setup tool I'm using is configured using XML files that contain, in them, LUA scripts that build and run the Windows Installer package command lines. Between the nested languages and various levels of escaping, I'd not noticed that the "/SECURITYMODE=SQL" argument was commented out, and not included in the command line.
With it included in the command line, the "sa" user is enabled.
TL;RD If you want the "sa" user enabled, after an install, include "/SECURITYMODE=SQL" on the command line.
You need to specify /SAPWD as well when using /SECURITYMODE=SQL. I am not sure, but if you do not specify the password, it will be disabled by default.
Have a look at this article https://learn.microsoft.com/en-us/sql/database-engine/install-windows/install-sql-server-from-the-command-prompt?view=sql-server-2017 for more information.
Some background:
I am running SQL Server 2012
Let's call the service account running SQL Server Agent: myserv-sa-sqlagent
Right now I have it set up so that I CAN: 1) log onto the server as myserv-sa-sqlagent, and 2) connect to the SSIS server via SSMS, and 3) SUCCESSFULLY RUN the package, let's call it myssispack.dtsx from Stored Packages -> MSDB -> [Folder] => myssispack.dtsx
In short then, if I wanted to log into the server as the service account (myserv-sa-sqlagent) and manually right click on each package in the SSIS server and "Run Package" -- I could successfully do that.
I cannot though call the package from SQL Server Agent job via a SSIS Package type step. Temporarily, I have made myserv-sa-sqlagent an administrator on the server.
Error message when trying to run the package from SQL Server Agent:
Connecting to the Integration Services service on the computer "[my server]" failed with the following error: "Access is denied." By default, only administrators have access to the Integration Services service. On Windows Vista and later, the process must be running with administrative privileges in order to connect to the Integration Services service. See the help topic for information on how to configure access to the service.
By default when you installed SQL Server all users in the Users group had access to the Integration Services service. When you install the current release of SQL Server, users do not have access to the Integration Services service. The service is secure by default. After SQL Server is installed, the administrator must grant access to the service.
To grant access to the Integration Services service:
Source MSDN
Run Dcomcnfg.exe. Dcomcnfg.exe provides a user interface for modifying certain settings in the registry.
In the Component Services dialog, expand the Component Services > Computers > My Computer > DCOM Config node.
Right-click Microsoft SQL Server Integration Services 11.0, and then click Properties.
On the Security tab, click Edit in the Launch and Activation Permissions area.
Add users and assign appropriate permissions, and then click Ok.
Repeat steps 4 - 5 for Access Permissions.
Restart SQL Server Management Studio.
Restart the Integration Services Service.
I have SSIS packages that have connections that use project params(only database and server), the actual login is set to windows authentication.
So when a SQL Server Agent runs that job step(package) how does it connect with windows authentication? Does it use it's own service account? If so as long as the service account has the same permissions as my windows account it shouldn't have issues right? All the objects in the SSIS packages are tables stored in that same server instance.
If I had external objects that use tables on different servers and such would it encounter issues then?
If the job owner is sysadmin and different server are in same domain it should be straight foward.
The secure way is to create a proxy on sql and give the Windows auth credentials. Then configured the package to run as "proxy defined".
I have created an SSIS package that will be deployed to client SQL installations (2005, 2008 or 2008 R2) to perform data extracts which provide a support tool for our product. The deployment process requires that a Windows AD account (normal user, no elevated privileges) is created as this is used as a service account to execute the SSIS package in a SQL Agent job by way of a credential and a proxy account. This all works perfectly and means I can restrict the privileges required to perform this job.
However, I wanted to include error logging in the SSIS package to the Windows Event Log. When I run the package in BIDS (which of course uses my own credentials) and force the failure of the package, it logs just fine. When I force the package to fail (by putting a duff connection string into the config file) whilst being run by the SQL Agent job, nothing is logged. The service account is being used and it is an authenticated user on my SQL Server host machine but it will not write to the event log. If I add the service account to the local administrators group, it writes to the log just fine, but I thought the idea of the Windows event log was that you did not need elevated privileges to write to it?
Our support teams are keen to use the Windows Event Log but I can see no way of doing so without granting high privileges to a service account which I would rather not do. Am I missing something? The Logging tab in the SSIS job step page doesn't seem to do a lot but perhaps that's what I'm missing?
Apologies if this is more suited to ServerFault, but I couldn't quite decide which side of the line this fell as it is a problem encountered during development. If it is then I'll relocate it.
Many thanks
Steve
If OS is 2003, check the SDDL syntax on who has access to write to the log with this: http://support.microsoft.com/kb/323076
If 2008, you can use wevtutil instead of manually typing in SDDL:
http://support.microsoft.com/kb/2028427
The service account can be given the permissions using the above.
I'm trying to run a SQL Agent Job with a step that is a SSIS File, and I need this step to be run as administrator.
My Package uses a Script task to download a file, as a Browser i Use WATIN.
I'm using a thread to start this browser because this browser control requires the thread to be set as Single-Threaded Apartment.
This browser control is requiring to be run as administrator.
I've already created a Credential for a user that is Windows Admin, a Proxy SSIS account. (SQL Agent user is not windows admin).
But the SSIS package is not run as administrator yet.
I'm suspecting this is related to UAC.
Some details:
SQL Agent Account is not Windows Administrator
Using Windows Server 2008 R2
My Package is run from the File System.
The Package only works on BIDS if I run it as an Administrator (if not admin doesn't work)
The Proxy account the job step is configured to run is windows admin.
Any help is appreciated!
Take a look at SSIS runs in BIDS but not with SQL Agent for some ideas
I've solved this in another way, The problem wasn't related to running the package as administrator, but creating a windows and setting focus to it, however I had the option to see the result file on the web page and I managed to use it, without downloading it, thus not needing to set focus on the download windows.
Thanks for all the help.
Try to add the user account in SSIS administrator group which can solve your problem.