I work at a college a change to policy is Students windows accounts are now disabled upon creation and are only enabled upon them passing a test. Don't ask
So I can easily modify my DSADD with -disabled yes
However I need to enable them when they pass the test. I obtain the test results from a sql server so is it possible to enable the accounts that have passed the test within t-sql?
I am just thinking it is easier to schedule a job on the sql server to do this as oppose to writing a program that checks the results every 5 minutes and having to keep making sure it is running and not forget about the programs existence.
Security comes down to SQL Sever from AD, not the other way around.
That said, you could write a query that would email you it's results.
You could write an SSIS package that would do the same thing.
Or, if you can figure out how parameterize the bits and pieces, you could write an SSIS pacakge that would use the "Execute Process Task" to send the right string to the command line.
Related
I am trying to create make a user Credential appear in RunAs when I select T-SQL as my job step. However, the user account didn't appear.
Following the steps here, I managed to create RunAs but when I select T-SQL, it didn't show up.
Create Credentials for our Windows Service Account
https://learn.microsoft.com/en-us/sql/relational-databases/security/authentication-access/create-a-credential?view=sql-server-ver15
Assign Job Run As at Step Level.
https://learn.microsoft.com/en-us/sql/ssms/agent/configure-a-user-to-create-and-manage-sql-server-agent-jobs?view=sql-server-ver15
Can't find any T-SQL in the subsystem
https://learn.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-grant-proxy-to-subsystem-transact-sql?view=sql-server-ver15
Any ideas on how I can get RunAs appear in T-SQL ? Under Proxies, how can I add new SubSystem ?
Thanks.
I don't believe you can add subsystems to the list of Proxies.
SQL Agent hasn't really had any love in quite sometime, so while Run As appears as a dropdown option when you first create a step with the default T-SQL command type, if you cycle to something else and then back to T-SQL you will see Run As is no longer an option (it's grayed out).
This means T-SQL will be executed as the Service Account that the Agent service runs under...
...Unless you impersonate another user!
Problem
I have developed an SSIS package for an ETL process, which I have deployed successfully to a remote server. I have windows and SQL logins for this server, but not admin. The data that this ETL process loads is generated on a different machine on a different domain early in the morning each day (i.e. before I get to work) and needs to be automatically loaded after the data generation process as soon as possible.
Currently, I manually run the ETL package in SSMS, and authenticate this by spoofing the windows user credentials on the remote server by launching SSMS with runas.exe. This is currently okay since we are in early development, but this is obviously not an acceptable solution in production. Hence, I would like to automate this process, since a) the data is extremely time sensitive and b) manually running this process is a PITA.
How should I go about automating execution of the ETL package such that:
Execution happens immediately after the data is available, and
No user input is required from me e.g. to enter passwords?
Attempted solutions
Scheduling a SQL server agent job on a schedule is not an option, because of the time sensitivity. (Also my sysadmin seems to have not enabled/disabled the SQL server agent)
Continuing to use runas.exe is not an option either, as the /netonly flag, which is required, and the /savecred flag, which would prevent the need for manual password entry, are mutually exclusive.
sqlcmd.exe can be scripted to run with a SQL user and password (bad practice putting passwords in plain text, I know) but then running a stored procedure that calls the SSIS package fails, as windows authentication is required to run the package.
I would strongly advice you to ask for working SQL Agent and create an Agent Job to run the package. This way has a lot of advantages:
Native Windows user credentials management with proxy accounts
You can configure specific values for package/project parameters, connection managers via SSMS interface
You can use environment references of SSIS 2012 and above, and manage it via SSMS as well
Job can be started on schedule or manually from SQL command. Thus you can automate package start.
In a nutshell - it is much easier to manage and you do not disclose user credentials needed to run the package - you might even do not know it.
For the alternative - you can try PsExec from SysInternals tools. It allows to start program on another computer explicitly specifying username and password as psexec \\server -u user -p password .... However, I would opt against it.
I set up a job to run a SSIS package in the SSIS Catalog, but the SSIS package doesn't start. If I right-click the package and run it, it completes successfully.
When I look in the execution history of the package in the Catalog, there is no sign that it the package was even started by the job.
I created a test package to make sure it isn't the specific package failing, so the package I'm testing with has a SQL Task that does a 'SELECT 1'. Still fails.
The job just stays in the "Executing" state until I stop the job.
I am running SQL Server 2014 Standard Edition, and running the job with a sysadmin account.
Why is the SQL Agent Job not running my package?
Edit: I had a look through this article but it either doesn't apply or I gave it a shot and it didn't work either.
Edit 2: I found an error under the SQL Server Agent Job History: Unable to terminate process 1850 launched by step 1 of job 0x5DAD5416FA09C445B82ABDBB49F75E38 (reason: Access is denied)
Does that mean my service account doesn't have enough permissions on the local machine? However, I AM able to run the job with DTEXEC using the service account without issues...
I have also faced this scenario many times but when I checked running the package manually,its completing successfully because I was using for each loop container and sequence container as well.In both cases for each loop and sequence were completing without validating other ones.So I checked precedence constraint and change it,Now it working and all the component ran successfully. Sometimes we miss to choose appropriate precedence constraint, there are many option like on Success ,failure,completion and then for you can choose values from Constraint ,Expression,Expression AND Constraint and Expression OR Constraint. Initially i was using Expression OR Constraint for success and now changed it to Expression AND Constraint, its working fine for me. You also need to do this,it will definitely work please try and let me know.
When you look at the connections in the SSIS package, did you put in a user id and password? If so, did you add a package password? The reason I ask is that if you don't add a package password, it will strip out things it thinks should be secure (like passwords). You might want to try putting the connection password in a configuration file, and add that file to the job. Either that or password encrypt the SSIS package but you will have to take special care when you run the package for the first time (or when you create the job) because you will need to provide the password that you used to encrypt the package.
Reboot fixes this issue. Reason is because if you look at this message. Unable to terminate process 1850. That is a windows process. I would say reboot. If you really like to enquire before rebooting. You could use sysinternals process explorer. Download it and use that to find process id 1850 which may be hung process in windows.
Thanks
Ali
I have to say that I hate myself for such general question as "What I am doing wrong?" but I simply have no idea what can be the problem:
I've created SSIS package that takes the data from flat files (CSV), counts the average on one of the columns, groups by date and writes it to the database and deletes the original file. All works fine when executed within SSIS, but when I am scheduling it within Server Agent it simply doesn't work - log reports success but there is no new data in the database and the .csv file exists in its original location.
I know the problem with protection level set up in SSIS, so I've changed it to "EncryptAllWithPassword" and I use the same password with Server Agent.
Here is a link to the Server Agent Job script (created as "script job as DROP and CREATE")
Edit: Just to make things weirder, using
dtexcec /f {filepath} /de {password}
executes program without problem. I know I can shedule such command in the Windows itself, but i'd like to keep all scheduled jobs in one place - in the Server Agent
EDIT: Solved by changing the path to UNC
There are two important things to remember when setting up packages to run via a SQL Server Agent job.
Use UNC paths for all file locations, no matter how simple. There is a high probability that the server will have a different view of the file structure than your development machine, so UNC paths ensure that both machines are referencing the same paths.
Use a proxy account to execute that package, as described here http://www.mssqltips.com/sqlservertip/2163/running-a-ssis-package-from-sql-server-agent-using-a-proxy-account/.
The proxy account must have access to the physical paths and the server objects.
This also allows for security stratification on your various packages (not all packages need access to everything).
I am having trouble sorting through all the information / various options in regards to Access 2007 used in a multi-user environment. Here is a brief description of my current situation. At work there is the "Business LAN" which I can log on and use to monitor two other servers via remote desktop. The business LAN is strictly controlled by our IT department and no one is permitted to install any software or drivers without their consent. I do have administrative privileges on both servers though.
The two servers that I log on to using RD are used for essentially the same task, which is to monitor and control the heat to different process lines. Each server runs a different program to accomplish this task but both programs use SQL Server as a back end.
I created two access databases (one on each server because they are currently behind seperate firewalls) in order to query information from the backend SQL side of these programs and combine it with relative information I have compiled in tables in order to add more detail to the data the programs are collecting. My program is still in the debug stage but ultimately this information can then be accessed by field techs / maintenance in order to make their job easier. Maintenance staff can also add even more information based on the status of repairs etc....Last, I have created reports which can be run by Managers / Engineers who are looking for an overall status of their area.
Both access db's are split so that the back ends are seperate from the forms, queries, etc... I use an ODBC data source to import a link to SQL. I am using vba for user authentication, user logging record updates, and user / group access control. Everything works the way I intended except the fact I everyone who logs on the server will be trying to run the same copy of the front end. For example, I had a co-worker log on to the server via RD to test the program and I logged on from my desk. After logging in I could see the forms he had open. Access was already running. Without being able to install access locally (or even runtime, due to IT restrictions) on to each individuals workstation, I'm not sure what approach to take to resolve this.
Additional info, Server 1
One of the servers is considered to be the "master server" in which a number of client stations "slave servers" all communicate with. The only way to access folders on themaster server is log on to the client station and run RD.
Server 2
This server is considered to be the "historian". It communicates with a terminal server in which users log on using RD and run applications which use SQL backend which resides on the historian. I have been able to set up shares so that certain folders are visible on the historian from the terminal server.
Can anyone tell me what my best option is?
Thanks in advance.
CTN
It's really crazy the way some IT departments do everything possible to make it hard to do your job well.
You allude to users logging on via Terminal Server. If so, perhaps you can store the front ends in the user profiles of their Terminal Server logons? This assumes they're not just using the two default admininstrative Terminal Server logons, of course.
The other thing that's not clear to me is why you need a back end at all in Access/Jet/ACE -- why not just link via ODBC to the SQL Server and use that data directly? The only reason to have an independent Jet/ACE file with data tables in it in that scenario is if there is data you're storing for your Access application that is not stored in the SQL Server. You might also have temp tables (e.g., for staging complicated reports, etc.), but those should be in a temp database on a per-user basis, not in a shared back end.
Here is a suggestion how to implement what David Fenton wrote: write a simple batch script which copies your frontend from the installation path to %TEMP% (the temporary folder of the current user session) and runs the frontend from there. Something along the lines of
rem make sure current directory is where the script is
cd /d %~d0%~p0
rem assume frontend.mdb is in the same folder as the script
copy /y frontend.mdb %temp%
start %temp%\frontend.mdb
Tell your users not to run the frontend directly, only via the batch script, then everyone should get his own copy of the frontend. Or, give your frontend a different suffix in the installation path and rename it to "frontend.mdb" when copying to %temp%.