It has been a while since I did it but you can make an entry configured as you want, export the registry key for that entry to imported on the other systems and if I'm mistaken you need to update the odbc.ini in system32. You can use AutoIT as well.
Cesar A. Meaning is NOT in words, but inside people! Dr. Myles Munroe My iPad takes half the blame for misspells. > On Oct 27, 2014, at 5:33 AM, Gavin Wilby <[email protected]> wrote: > > Hi, > > The preference is for it to be a System DSN. > > The dev is a senior manager, I asked straightaway about the sa password and > was asked “what difference does it make, the user cant see it” > > Sometimes its just not worth the confrontation. > > Gavin Wilby > IT Support Engineer > > From: [email protected] [mailto:[email protected]] > On Behalf Of Ken Schaefer > Sent: 27 October 2014 12:23 > To: [email protected] > Subject: [NTSysADM] RE: Pushing out ODBC connections > > ODBC connections can be user (stored in user reg hive), system (stored in reg > for all users) or file based. > > So, on the client side, what type of ODBC data source is acceptable? Can the > app reference a file ODBC DSN – dunno if that’s acceptable security wise. > Otherwise, does it need to be system wide or user specific? Either way, you > can use your deployment tool to push it out. > > And TBH, why does it need to connect with “sa”? Surely another SQL Server > identity can be created (even with the same privileges as “sa”, and then > reduced accordingly over time as the dev figures it out). You need to push > back on this last part. > > From: [email protected] [mailto:[email protected]] > On Behalf Of Gavin Wilby > Sent: Monday, 27 October 2014 11:03 PM > To: '[email protected]' > Subject: [NTSysADM] Pushing out ODBC connections > > Hi, > > I have been asked by one of our Devs, to push out a ODBC connection to a > database server. > > The issue is that is HAS to connect with the servers SA username and > password… <sigh> > > I cant see how exactly how this can be pushed out by either a registry script > or by GPP… anyone done this successfully? > > Gavin Wilby > > <random stuff snipped> > SMP Partners Limited, SMP Trustees Limited and SMP Fund Services Limited are > licensed by the Isle of Man Financial Supervision Commission. SMP Accounting > & Tax Limited is a member of the ICAEW Practice Assurance Scheme. > SMP Partners Limited registered in the Isle of Man, Company Registration No: > 000908V > Directors: M.W. Denton, M.J. Derbyshire, P.N. Eckersley, S.E McGowan, O. > Peck, J.J. Scott, S.J. Turner > SMP Trustees Limited registered in the Isle of Man, Company Registration No: > 068396C > Directors: A.C. Baggesen, M.W. Denton, O. Peck, J.J. Scott, J. Watterson, J. > Cubbon > SMP Fund Services Limited registered in the Isle of Man, Company Registration > No: 120288C > Directors: V. Campbell, M.W. Denton, P.N. Eckersley, D.A. Manser, S.E > McGowan, O. Peck, J.J. Scott, R.K. Corkill > SMP Accounting & Tax Limited registered in the Isle of Man, Company > Registration No: 001316V > Directors: I.F. Begley, A.J. Dowling, P. Duchars, P.N. Eckersley, J.J. > Scott, S.J. Turner > SMP Capital Markets Limited registered in the Isle of Man, Company > Registration No: 002438V > Directors: M.W. Denton, M.J. Derbyshire, D.F Hudson, S.E McGowan, O. Peck, > J.J. Scott. > SMP Partners Limited, SMP Trustees Limited, SMP Fund Services Limited, SMP > Accounting & Tax Limited and SMP Capital Markets Limited are members of the > SMP Partners Group of Companies. > This email is confidential and is subject to disclaimers. Details can be > found at: http://www.smppartners.com/disclaimer.html > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________
