ODBC password



  • tWvH7c2.png

    Is there any way, via a registry or GPO, to fill in the field shown? I've done some searching and there doesn't seem to be anything that actually works. Most suggest to edit the HKLM/Software/ODBC/ODBC.INI/<dsn_name>/password Key, or to add it. I've done that and then the ODBC tool doesn't update after changing it.



  • My guess would be that the password would've been salted at the original time of entry, and can't be used to repopulate the field.



  • Are you installing SQL because of another program? If so, look thru the program's instruction, you may find what you need.



  • This is for a VDI environment and the registry or ODBC settings have to be populated through GPO. Everything else is working in the GPO to fill in all fields for the system DSN but the password is the only thing NOT populating.



  • @Grey said in ODBC password:

    This is for a VDI environment and the registry or ODBC settings have to be populated through GPO. Everything else is working in the GPO to fill in all fields for the system DSN but the password is the only thing NOT populating.

    I think they took that ability out of the GPO a while back. Can you not pre-populate the VDI image with the appropriate ODBC connections and redeploy?



  • @dafyre said in ODBC password:

    @Grey said in ODBC password:

    This is for a VDI environment and the registry or ODBC settings have to be populated through GPO. Everything else is working in the GPO to fill in all fields for the system DSN but the password is the only thing NOT populating.

    I think they took that ability out of the GPO a while back. Can you not pre-populate the VDI image with the appropriate ODBC connections and redeploy?

    I tried that. No joy.



  • @Grey said in ODBC password:

    tWvH7c2.png

    I've done that and then the ODBC tool doesn't update after changing it.

    Did you reboot 3 times?



  • You could also try exporting the registry key from a known working machine, and copying it out to a .reg file and applying that .reg file via GPO?



  • @dafyre said in ODBC password:

    You could also try exporting the registry key from a known working machine, and copying it out to a .reg file and applying that .reg file via GPO?

    Tried this, too. That is how we got as far as we did.



  • @Grey said in ODBC password:

    @dafyre said in ODBC password:

    You could also try exporting the registry key from a known working machine, and copying it out to a .reg file and applying that .reg file via GPO?

    Tried this, too. That is how we got as far as we did.

    Microsoft secured something so well not even the sysadmin can configure it for the end users?



  • @travisdh1 said in ODBC password:

    @Grey said in ODBC password:

    @dafyre said in ODBC password:

    You could also try exporting the registry key from a known working machine, and copying it out to a .reg file and applying that .reg file via GPO?

    Tried this, too. That is how we got as far as we did.

    Microsoft secured something so well not even the sysadmin can configure it for the end users?

    AKA: They fixed it until it was broke.



  • If it ain't broke... fix it.



  • @Texkonc said in ODBC password:

    @Grey said in ODBC password:

    tWvH7c2.png

    I've done that and then the ODBC tool doesn't update after changing it.

    Did you reboot 3 times?

    No, that's run iisreset then reboot three times.



  • @Texkonc said in ODBC password:

    @Grey said in ODBC password:

    tWvH7c2.png

    I've done that and then the ODBC tool doesn't update after changing it.

    Did you reboot 3 times?

    Rebooting a linked clone is ... more than rebooting.



  • Update: I've found that you can make a file.dsn and store your connection details there, e.g:
    [ODBC]
    DRIVER=SQL Server Native Client 11.0
    UID=<username_sql>
    DATABASE=<SQL Database Name>
    APP=Microsoft® Windows® Operating System
    SERVER=<SQL Server Hostname>
    Description=<Anything or nothing>
    PWD=<The critical piece>

    With a .dsn file, you can open the ODBC application and import the settings, similar to an outlook client connecting to the first time where it gathers the info from DNS & autodiscover, except that this gathers from the file. Obviously, a user would have to be admin level to import the file.

    These settings are all stored, with the exception of the password, in HKLM\Software\ODBC\ODBC.INI<name> and it's important to note that multiple items are stored which requires one to export the whole tree from ODBC.INI down, not just the name of the ODBC source that you want to configure; the driver information is in a different key than the configured source.

    I am still looking over how to get the password to either be stored, or force it to import in another way without using a stupid bat file, which seems to be the preferred method. I hate, hate, hate using bat files in modern GPO systems.

    I'll update if I find more, though i would appreciate it if anyone else can add to this, especially if you have a solution.



  • There's an App called Whatchanged...

    Start on a machine without the ODBC connection...

    Run Whatchanged, and let it scan the registry.

    Add the ODBC conneciton, and let it scan again to see where it is (may be) putting the password in the registry...

    http://www.majorgeeks.com/mg/getmirror/what_changed,1.html -- It's an older App, but it still works.


Log in to reply
 

Looks like your connection to MangoLassi was lost, please wait while we try to reconnect.