Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

SQLCMD problems Expand / Collapse
Author
Message
Posted Tuesday, January 21, 2014 7:23 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Friday, December 19, 2014 6:34 AM
Points: 439, Visits: 1,015
What I'm trying to accomplish is to write network logons / logoffs to a SQL server.

We've set up a group policy on the OU, and want to call SQLCMD to write the info to a table. Sounds simple enough. We have logon.cmd and logoff.cmd which set the parameters and call SQLCMD.

I'm trying to call a local copy of SQLCMD.exe -- we don't want users having access to the C:\Program Files\... -- and getting various errors:

- if I call SQLCMD v. 2009.100.2500.0, I get SQLCMD is not a valid Win32 app.
- if I call SQLCMD v. 2009.100.1600.0, I get BatchParser.dll (2009.100.1600.1) is not a valid Windows image

We're using SQL 2008 R2 sp1 on a Win2008 R2 sp1 box.

How can I make this work?

Thanks



Post #1533054
Posted Tuesday, January 21, 2014 7:33 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 9:39 AM
Points: 5,490, Visits: 10,347
I don't think it'll work if you just lift sqlcmd.exe and copy it somewhere else. It needs access to all sorts of DLLs and other stuff. Why can't you just create a desktop shortcut to the file in the prohibited folder?

John
Post #1533062
Posted Tuesday, January 21, 2014 7:56 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Friday, December 19, 2014 6:34 AM
Points: 439, Visits: 1,015
"...just create a desktop shortcut to the file in the prohibited folder?"

I'm sorry, I don't follow.

The logon/logoff.cmd files called by the policy are sitting on the SQL Server in question, and should be calling SQLCMD on that server, no?



Post #1533092
Posted Tuesday, January 21, 2014 8:01 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 9:39 AM
Points: 5,490, Visits: 10,347
OK, I didn't quite understand first time. You have these two .cmd files that are triggered automatically whenever a logon or logoff event occurs (presumably on AD) - is that right? If that's the case, no users need to go anywhere near sqlcmd.exe or the .cmd files, do they?

John
Post #1533101
Posted Tuesday, January 21, 2014 8:28 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Friday, December 19, 2014 6:34 AM
Points: 439, Visits: 1,015
Yes, that's correct, they're fired by AD group policy.

So yes, I don't think the .cmds are called in the users' context. In fact, they would likely be running under a domain admin account... so privs shouldn't be an issue, right?

Going to work w/ my domain admin, I'll get back to you if still unresolved.




Post #1533121
Posted Tuesday, January 21, 2014 12:37 PM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Friday, December 19, 2014 6:34 AM
Points: 439, Visits: 1,015
Still no joy.

Maybe we're going about this the wrong way.

Let me back up: A Group policy is set, and what we want to happen is
1) A user logs into domain
2) A row is inserted in a SQL Server database table on same domain in realtime. User does not necessarily have access to SQL Server.

Any suggestions? We're about to revert to the tried and true parsing of logs....

P











Post #1533316
Posted Wednesday, January 22, 2014 1:54 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 9:39 AM
Points: 5,490, Visits: 10,347
You haven't said what exactly isn't working. I suspect that your problem is how to fire triggers from events in AD. If that's the case, you'd be better off posting on a more suitable forum.

John
Post #1533496
Posted Wednesday, January 22, 2014 5:21 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Friday, December 19, 2014 6:34 AM
Points: 439, Visits: 1,015
What isn't working is getting SQLCMD to run in the context of the user that's login in/out.
I had assumed that the policy would execute under a system/admin account.

But you're right, I'll seek help in more appropriate fora.

Thanks John.




Post #1533569
Posted Wednesday, January 22, 2014 5:28 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 12:39 PM
Points: 6,760, Visits: 14,412
schleep (1/22/2014)
What isn't working is getting SQLCMD to run in the context of the user that's login in/out.
I had assumed that the policy would execute under a system/admin account.

But you're right, I'll seek help in more appropriate fora.

Thanks John.


Embed the query in a SP and create the stored proc with execute as owner, that way it wont care who executes it


-----------------------------------------------------------------------------------------------------------

"Ya can't make an omelette without breaking just a few eggs"
Post #1533572
Posted Wednesday, January 22, 2014 8:05 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Friday, December 12, 2014 3:32 AM
Points: 1,639, Visits: 5,721
schleep (1/22/2014)
What isn't working is getting SQLCMD to run in the context of the user that's login in/out.
I had assumed that the policy would execute under a system/admin account.


If you're doing it via a conventional login script, then no, that doesn't execute as a sysadmin account--it wouldn't be terribly useful if it *did*, because login scripts are supposed to do stuff that's specific to the user logging in, not some random admin user. This is probably why it's not working.
Post #1533659
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse