quick help is needed

  • I have a domain user account and it is given

    an administrator's right on my SQL server machine. When I installed the SQL Server to the server machine, I logged in as this domain user. The result is during the installation, some of the files did not copy to the local server (the SQL server is installed to E:\Program Files\Microsoft), but got copied to M:\Program Files\Common Files\... in other server which is automactically mapped as M: when I log in. When the M: drive is mapped, the SQL Server works well. However, when I disconnect to M: drive or remotely access to the SQL Server server (in that case, M: is not mapped), I can't access to the resources in the SQL Server databases.

    My question is why SQL Server installer copies some of the files (all these files are under Program Files\Common Files\) to the M: drive rather than local drives, such as E: or C:? How can I correct this problem?

    The derived problem I have now is after I un-installed the SQL Server and try to re-install it, the M: has to be mapped. Otherwise, the installation just can't even go on at the very begining. So what is the right way to clean up the SQL Server component so that it does not remember what happens in the previous installation?

    any quick solutions on these two will be appreciated.

  • Not sure what's wrong. I'd try the install and then search for all files changed in the last day. Should clue you in.

    Steve Jones

    steve@dkranch.net

  • You may need to dig in the registry, if it is rememebring anything it is most likely tin there. Personally if I could do it I would wipe the server and install the OS from scratch then SQL. How far does the install go before it fails by the way?

  • We had this problem when trying to install SQL 2K on a box where we had already remapped the drives... we didn't have time to figure it out (which is why my desktop is running the data store for the test farm, but that's another story).

    The problem comes in that the Common Files directory is set to a certain path in a variable. I believe if you have a roaming profile it may be set to your M:\ drive. So it'll try and install files there under M:\Program Files\Common Files\... and this will bite you on the reinstall. The local administrator account (or whatever it is renamed to) will have a local profile, not a roaming one, so it's Common Files should be pointing to a local drive. Then, once you get SQL Server up and running, you can change the service accounts for SQL Server, SQL Server Agent, etc.

    As far as reinstalling, you'll probably need to go in and remove all the registry keys for SQL Server as Antares has suggested. When a SQL Server 7 install crashed and burned on one of my contractors, that's what I had to do in order to get the install working again.

    Look under: \\KEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server

    And here's the boilerplate warning... make sure you have a backup of the registry as altering the registry can cause system problems to include system failure if the wrong values are deleted or altered. If you don't feel comfortable with going into the registry, take Antares advice and wipe the system and reload.

    K. Brian Kelley

    bkelley@sqlservercentral.com

    http://www.sqlservercentral.com/columnists/bkelley/

    K. Brian Kelley
    @kbriankelley

  • Thank you all for good suggestions. I actually tried to delete the registry for SQL server, but I guess their entries spread in more than just \\KEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server. So it does not really help to solve the problem completely. I agree that in order to redo it right for sure, I need to wipe out the entire OS and re-install everything which is a bit too much.

    The last thing I did is to login as the real domain "Administrator" and re-install everything. In this case, at least it does not write files to my M: drive as it does when I login in as jzhou which has local administrator right.

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply