down grading can i?

It seems as though our last administrator has installed Enterprise Licenses (SQL 2005) We need these to be Standard, can I down grade some how with minimal to no disruption to our databases?

If so How, if not (which i almost positive that you are going to say NO) then i assume I am going to have to reinstall the SQL server. What is the best way going about this with out having to restore all of the databases? Can i copy all of the MDF and LDF files else where and then once the new installation has completed create the users, then databases and then replace the MDF and LDF?

Is there a better way then this if so it would be a huge help.

Thanks

Brad

I believe that it will be necessary to remove SQL Enterprise Edition and reinstall SQL Standard Edition. Enterprise Edition installs some supporting files that are not allowed with Standard Edition so you cannot simply 'downgrade' the license since you would still have the functionality.

Make a set of complete FULL backups, including master and msdb. Restore them after you have reinstalled Standard Edition. Or copy the mdf/ldf files, recreate any SQL Users, then ATTACH the databases.

|||Arnie Rowland is correct. Downgrading SQL Server Enterprise to other SQL Server SKUs is not supported.sql

down grading can i?

It seems as though our last administrator has installed Enterprise Licenses (SQL 2005) We need these to be Standard, can I down grade some how with minimal to no disruption to our databases?

If so How, if not (which i almost positive that you are going to say NO) then i assume I am going to have to reinstall the SQL server. What is the best way going about this with out having to restore all of the databases? Can i copy all of the MDF and LDF files else where and then once the new installation has completed create the users, then databases and then replace the MDF and LDF?

Is there a better way then this if so it would be a huge help.

Thanks

Brad

I believe that it will be necessary to remove SQL Enterprise Edition and reinstall SQL Standard Edition. Enterprise Edition installs some supporting files that are not allowed with Standard Edition so you cannot simply 'downgrade' the license since you would still have the functionality.

Make a set of complete FULL backups, including master and msdb. Restore them after you have reinstalled Standard Edition. Or copy the mdf/ldf files, recreate any SQL Users, then ATTACH the databases.

|||Arnie Rowland is correct. Downgrading SQL Server Enterprise to other SQL Server SKUs is not supported.

Doubling up security on SQL Server system administrator

Hi All
Always baffled me this, but although I can set up complex SQL usernames and
passwords for my SQL database the main system administrator login details
only give me half the security because the username is always 'sa'. I can
only set a complex password for the most powerful user of them all.
This might be a very newbie question, but is it possible (and advisable -
knowing Microsoft's progs don't like changing core settings after the event)
to change the system admin's username to something else?
Please note that I already have a number of databases running on this SQL
server installation so would this implicate their use if I changed it?
Rgds
RobbieSee reply in .setup
HTH
Jasper Smith (SQL Server MVP)
http://www.sqldbatips.com
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Astra" <info@.NoEmail.com> wrote in message
news:eqYQsd%239EHA.2680@.TK2MSFTNGP09.phx.gbl...
> Hi All
> Always baffled me this, but although I can set up complex SQL usernames
> and
> passwords for my SQL database the main system administrator login details
> only give me half the security because the username is always 'sa'. I can
> only set a complex password for the most powerful user of them all.
> This might be a very newbie question, but is it possible (and advisable -
> knowing Microsoft's progs don't like changing core settings after the
> event)
> to change the system admin's username to something else?
> Please note that I already have a number of databases running on this SQL
> server installation so would this implicate their use if I changed it?
> Rgds
> Robbie
>|||Robbie,
Did you ever get the answer to this? I want to do the same as you -
how do I do it?
Darren.
Astra wrote:
> *Hi All
> Always baffled me this, but although I can set up complex SQL
> usernames and
> passwords for my SQL database the main system administrator login
> details
> only give me half the security because the username is always 'sa'.
> I can
> only set a complex password for the most powerful user of them all.
> This might be a very newbie question, but is it possible (and
> advisable -
> knowing Microsoft's progs don't like changing core settings after the
> event)
> to change the system admin's username to something else?
> Please note that I already have a number of databases running on this
> SQL
> server installation so would this implicate their use if I changed
> it?
> Rgds
> Robbie *
railex
---
Posted via http://www.mcse.ms
---
View this thread: http://www.mcse.ms/message1342852.html

Dont know where to put a subfunction/query into my SQL Script

Hi,

I'm kind of database administrator in our company and have to manage a project database, where people add their work times to a SQL database (Access frontend). Like time they work on a day, on a specific project, vacances etc.).

I made a script which reports me:
- for each person, how long did they work on a project (Auftrag_ID) on a single day
- limited by a period (Monat_von to Monat_bis means month_from to month_to)

The script was fine, but I now had also to output a comment for every week for each person and then for each of the persons Auftrag_IDs (projects) so I inner joined the Table "WO-Zeiterfassung" where this information is stored. But I have to found out for each date, which is the date of the sunday in that week to Innerjoin it on the sunday date (I'm not sure if there is an easier way)... so for the moment I made a "subscript", function whatever you call that, to give me the date of the sunday for each day, which I marked in the code below. But I have no idea where I must put that part into the query AND if it is correct :-) the same goes with the inner join part of the query (also marked with commentary code):

DECLARE @.Auftrag_ID int
DECLARE @.Jahr int
DECLARE @.Monat_von int
DECLARE @.Monat_bis int

DECLARE @.Wochentag int
DECLARE @.DifferenzTage int
DECLARE @.WoSonntagsDatum datetime

SELECT @.Auftrag_ID = '3216'
SELECT @.Jahr = '2006'
SELECT @.Monat_von = '1'
SELECT @.Monat_bis = '4'

SET DATEFIRST 1

/* WHERE TO PUT THE FOLLOWING PART, and is it correct? */
(
SET @.Wochentag = (SELECT Datepart(dw, TKMA.Datum))
SET @.DifferenzTage = ( 7-@.Wochentag )
SET @.WoSonntagsDatum = (SELECT DateAdd(d, @.DifferenzTage, TKMA.Datum))
)
/* ende */

SELECT
Personal.[Personal-ID]
,Personal.[Name] + ' ' + Personal.[Vorname] AS NameVorname
,KstStell.[KostenstellenNo] AS KstSt
,KstStell.[Kostenstellenname] AS KstName
,TKMA.[Auftrag-ID]
,TKMA.[Auftrag-Kurzbezeichnung]
,KstStell.[Kostenstellenverant]
,Personal2.[Name] + ' ' + Personal2.[Vorname] AS ProjVerantwortlicher
,TKMA.Datum
,MONTH(TKMA.Datum) AS Monat
,TKMA.Stunden
,TKMA.ProjektNrIntern AS ProjNrIntern
,TKMA.ProjektNr AS ProjNr
,TKMA.Projektkurzbezeichnung AS ProjBezeichnung
,TKMA.Erf_abgeschlossenJN AS abgeschlossen
,TKMA.KJahr AS Jahr
FROM
Tageskalender_MA_Details TKMA
INNER JOIN
[Personal_maXis] Personal ON Personal.[Personal-ID] = TKMA.[Personal-ID]
INNER JOIN
[Kostenstellen maXis] KstStell ON Personal.[KSTNR-ID] = KstStell.[KSTNR-ID]
INNER JOIN
[Projekte] Prj ON TKMA.[ProjektNrIntern] = Prj.[ProjektNrIntern]
/* AND HERE THE INNERJOIN RELATED PART I ADDED FOR THIS NEW STUFF */
INNER JOIN
[WO-Zeiterfassung] WOZE ON @.WoSonntagsDatum = WOZE.[So-Datum] AND Personal.[Personal-ID] ON WOZE.[Personal-ID] AND TKMA.[Auftrag-ID] ON WOZE.[Auftrag-ID]
/* TILL HERE */
LEFT OUTER JOIN
[Personal_maXis] Personal2 ON Personal2.[Personal-ID] = Prj.[Personal-ID]
WHERE
(TKMA.[Auftrag-ID] = @.Auftrag_ID)
AND
(TKMA.KJahr = @.Jahr)
AND
(MONTH(TKMA.Datum) >= @.Monat_von)
AND
(MONTH(TKMA.Datum) <= @.Monat_bis)
AND
(TKMA.Erf_abgeschlossenJN = '-1')

Here is the error it outputs in query analyzer:
Server: Msg 156, Level 15, State 1, Line 20
Incorrect syntax near the keyword 'SET'.
Server: Msg 170, Level 15, State 1, Line 23
Line 23: Incorrect syntax near ')'.
Server: Msg 156, Level 15, State 1, Line 53
Incorrect syntax near the keyword 'ON'.

I've no clue what I make wrong :-\

Hope someone can help me,

ShihanI think SQL Server is expecting a "From Clause" in the following:

SET @.Wochentag = (SELECT Datepart(dw, TKMA.Datum))

Domain User privilege for connecting SQL server 2000

Hi,

My server administrator has created a few users as domain user privilege for connecting SQL server from my application. However it faild to connect, and

with Domain Admin privilege, my app is running ok.

I asked admin person to upgrade domain user privilege to connect SQL server,

but he couldn't do this for security reason, and told it should work with domain user.

Is it true for domain user to connect SQL server without any problem?

Do I need to add the user, domain user, into Logins of Security inside SQL server Enterprise Manager?

Or inside users of my database section of SQL server EManager?

Thanks,

dixon

You have to create a login in SQL Server 2000 that corresponds to the domain user. Look at sp_grantlogin:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_sp_ga-gz_8dri.asp

Thanks
Laurentiu

Domain Administrator Password Change Fails File output

Windows 2003 Ent.
RS 2000
SQLSERVER 2000 Ent.
The networking group changed the domain administrator password. I have
changed the RS serverice in the control panel. I have changed all the
subscriptions to use the new password. I have used the RSCONFIG with the -e
and -u to supply the domain administrator password change but they still do
not export to the file share. Any responses would be helpfull!!Are the reports rendering correctly? I'd like to view the log files first.
You can zip and email them to me at v-rxwang@.microsoft.com.
Sincerely,
William Wang
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
This posting is provided "AS IS" with no warranties, and confers no rights.|||Hi Scott,
I've received the log files. From the ReportServerService__<datetime> logs
I can see:
ReportingServicesService!crypto!1114!8/3/2005-20:03:48:: i INFO:
Initializing crypto as user: INTERINTRA\Administrator
ReportingServicesService!crypto!1114!8/3/2005-20:03:48:: i INFO: Exporting
public key
ReportingServicesService!library!1114!8/3/2005-20:03:48:: Exception caught
while starting service. Error: System.Runtime.InteropServices.COMException
(0x8009000B): Key not valid for use in specified state.
This indicates a encryption key and Reporting Services Windows Service
account problem. I suggest that you follow these steps:
1. Backed up ReportServer and ReportServerTempdb
2. Run rskeymgmt -e -f <name> -p <password>
3. Run rskeymgmt -d
4. Restarted the ReportServerservice and access the reportserver via
http://servername/reportserver to activate it.
5. Test and see if the subscriptions still have the problem. If the problem
still exists, zip and email the log files to me again please.
Sincerely,
William Wang
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
This posting is provided "AS IS" with no warranties, and confers no rights.|||Thank you for all your help!
Scott
"William Wang[MSFT]" wrote:
> Hi Scott,
> I've received the log files. From the ReportServerService__<datetime> logs
> I can see:
> ReportingServicesService!crypto!1114!8/3/2005-20:03:48:: i INFO:
> Initializing crypto as user: INTERINTRA\Administrator
> ReportingServicesService!crypto!1114!8/3/2005-20:03:48:: i INFO: Exporting
> public key
> ReportingServicesService!library!1114!8/3/2005-20:03:48:: Exception caught
> while starting service. Error: System.Runtime.InteropServices.COMException
> (0x8009000B): Key not valid for use in specified state.
> This indicates a encryption key and Reporting Services Windows Service
> account problem. I suggest that you follow these steps:
> 1. Backed up ReportServer and ReportServerTempdb
> 2. Run rskeymgmt -e -f <name> -p <password>
> 3. Run rskeymgmt -d
> 4. Restarted the ReportServerservice and access the reportserver via
> http://servername/reportserver to activate it.
> 5. Test and see if the subscriptions still have the problem. If the problem
> still exists, zip and email the log files to me again please.
> Sincerely,
> William Wang
> Microsoft Online Partner Support
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> This posting is provided "AS IS" with no warranties, and confers no rights.
>|||It's my pleasure!
Sincerely,
William Wang
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
This posting is provided "AS IS" with no warranties, and confers no rights.

Domain administrator password change

Hi folks. Sorry if this one's a bit basic, but I'm a SQL 2000 novice.
I've just taken over responsability for some servers and I need to
change the domain administrator password.
I was wondering if changing this will have any adverse affects on SQL.
The SQL server is a domain controller. Only the SQLSERVERAGENT service
uses the administrator account.
Will I have any problems "internal" to SQL after the password is changed?
Thanks for any tips.

Hi,
After the change you need to change the password for SQLServer Agent with
new password.
How to change the startup account:-
1. Control Panel - Admin tools -- Services
2. Double click above the SQLSERVERAGENT service
3. In the Log on tab, change the OS user name and enter the password, Click
ok and restart the service.
Thanks
Hari
SQL Server MVP
"David Pounds" <david.pounds@.hohohohohohahahahahah.bum> wrote in message
news:Oaib5H5VFHA.132@.TK2MSFTNGP14.phx.gbl...
> Hi folks. Sorry if this one's a bit basic, but I'm a SQL 2000 novice.
> I've just taken over responsability for some servers and I need to change
> the domain administrator password.
> I was wondering if changing this will have any adverse affects on SQL.
> The SQL server is a domain controller. Only the SQLSERVERAGENT service
> uses the administrator account.
> Will I have any problems "internal" to SQL after the password is changed?
> Thanks for any tips.
>
|||Nice one - thought that was it but always good to check.
Thank you.
Hari Prasad wrote:
> Hi,
> After the change you need to change the password for SQLServer Agent with
> new password.
> How to change the startup account:-
> 1. Control Panel - Admin tools -- Services
> 2. Double click above the SQLSERVERAGENT service
> 3. In the Log on tab, change the OS user name and enter the password, Click
> ok and restart the service.
> Thanks
> Hari
> SQL Server MVP
> "David Pounds" <david.pounds@.hohohohohohahahahahah.bum> wrote in message
> news:Oaib5H5VFHA.132@.TK2MSFTNGP14.phx.gbl...
>
>

Domain administrator password change

Hi folks. Sorry if this one's a bit basic, but I'm a SQL 2000 novice.
I've just taken over responsability for some servers and I need to
change the domain administrator password.
I was wondering if changing this will have any adverse affects on SQL.
The SQL server is a domain controller. Only the SQLSERVERAGENT service
uses the administrator account.
Will I have any problems "internal" to SQL after the password is changed?
Thanks for any tips.
:)Hi,
After the change you need to change the password for SQLServer Agent with
new password.
How to change the startup account:-
1. Control Panel - Admin tools -- Services
2. Double click above the SQLSERVERAGENT service
3. In the Log on tab, change the OS user name and enter the password, Click
ok and restart the service.
Thanks
Hari
SQL Server MVP
"David Pounds" <david.pounds@.hohohohohohahahahahah.bum> wrote in message
news:Oaib5H5VFHA.132@.TK2MSFTNGP14.phx.gbl...
> Hi folks. Sorry if this one's a bit basic, but I'm a SQL 2000 novice.
> I've just taken over responsability for some servers and I need to change
> the domain administrator password.
> I was wondering if changing this will have any adverse affects on SQL.
> The SQL server is a domain controller. Only the SQLSERVERAGENT service
> uses the administrator account.
> Will I have any problems "internal" to SQL after the password is changed?
> Thanks for any tips.
> :)|||Nice one - thought that was it but always good to check.
Thank you.
Hari Prasad wrote:
> Hi,
> After the change you need to change the password for SQLServer Agent with
> new password.
> How to change the startup account:-
> 1. Control Panel - Admin tools -- Services
> 2. Double click above the SQLSERVERAGENT service
> 3. In the Log on tab, change the OS user name and enter the password, Click
> ok and restart the service.
> Thanks
> Hari
> SQL Server MVP
> "David Pounds" <david.pounds@.hohohohohohahahahahah.bum> wrote in message
> news:Oaib5H5VFHA.132@.TK2MSFTNGP14.phx.gbl...
>>Hi folks. Sorry if this one's a bit basic, but I'm a SQL 2000 novice.
>>I've just taken over responsability for some servers and I need to change
>>the domain administrator password.
>>I was wondering if changing this will have any adverse affects on SQL.
>>The SQL server is a domain controller. Only the SQLSERVERAGENT service
>>uses the administrator account.
>>Will I have any problems "internal" to SQL after the password is changed?
>>Thanks for any tips.
>>:)
>
>

Domain administrator password change

Hi folks. Sorry if this one's a bit basic, but I'm a SQL 2000 novice.
I've just taken over responsability for some servers and I need to
change the domain administrator password.
I was wondering if changing this will have any adverse affects on SQL.
The SQL server is a domain controller. Only the SQLSERVERAGENT service
uses the administrator account.
Will I have any problems "internal" to SQL after the password is changed?
Thanks for any tips.
Hi,
After the change you need to change the password for SQLServer Agent with
new password.
How to change the startup account:-
1. Control Panel - Admin tools -- Services
2. Double click above the SQLSERVERAGENT service
3. In the Log on tab, change the OS user name and enter the password, Click
ok and restart the service.
Thanks
Hari
SQL Server MVP
"David Pounds" <david.pounds@.hohohohohohahahahahah.bum> wrote in message
news:Oaib5H5VFHA.132@.TK2MSFTNGP14.phx.gbl...
> Hi folks. Sorry if this one's a bit basic, but I'm a SQL 2000 novice.
> I've just taken over responsability for some servers and I need to change
> the domain administrator password.
> I was wondering if changing this will have any adverse affects on SQL.
> The SQL server is a domain controller. Only the SQLSERVERAGENT service
> uses the administrator account.
> Will I have any problems "internal" to SQL after the password is changed?
> Thanks for any tips.
> |||Nice one - thought that was it but always good to check.
Thank you.
Hari Prasad wrote:
> Hi,
> After the change you need to change the password for SQLServer Agent with
> new password.
> How to change the startup account:-
> 1. Control Panel - Admin tools -- Services
> 2. Double click above the SQLSERVERAGENT service
> 3. In the Log on tab, change the OS user name and enter the password, Clic
k
> ok and restart the service.
> Thanks
> Hari
> SQL Server MVP
> "David Pounds" <david.pounds@.hohohohohohahahahahah.bum> wrote in message
> news:Oaib5H5VFHA.132@.TK2MSFTNGP14.phx.gbl...
>
>
>

domain administrator password and sql services startup

A reality check please...
After changing the domain administrator password, we are no longer
able to connect to databases on a MS SQL Server 2000 server when
attempting to use ODBC drivers from W2K workstations.
The MSSQLSERVER and SQLSERVERAGENT services both show DomainName
\Administrator under the "Logon under This Account" in the 'Logon' tab
in services.msc. The server name inside the SQL server are set to
mixed mode.
Am I correct in thinking that changing the password field shown in the
"Login under This account:DomainName\Administrator to match the new
domain administrator password will bring Joy?
Thanks!
Benoit
(Cross-posted to microsoft.public.sqlserver.server,
microsoft.public.sqlserver.setup, microsoft.public.sqlserver.odbc)
Hello,
Yes, if the Windows account used by the SQL Server services has a new
password you should update it here or by using Enterprise Manager.
Also, it would be better if you use a dedicated Windows account for SQL
Server instead of the domain administrator account.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"bntgoogle@.yahoo.com" wrote:

> A reality check please...
> After changing the domain administrator password, we are no longer
> able to connect to databases on a MS SQL Server 2000 server when
> attempting to use ODBC drivers from W2K workstations.
> The MSSQLSERVER and SQLSERVERAGENT services both show DomainName
> \Administrator under the "Logon under This Account" in the 'Logon' tab
> in services.msc. The server name inside the SQL server are set to
> mixed mode.
> Am I correct in thinking that changing the password field shown in the
> "Login under This account:DomainName\Administrator to match the new
> domain administrator password will bring Joy?
> Thanks!
> Benoit
> (Cross-posted to microsoft.public.sqlserver.server,
> microsoft.public.sqlserver.setup, microsoft.public.sqlserver.odbc)
>

domain administrator password and sql services startup

A reality check please...
After changing the domain administrator password, we are no longer
able to connect to databases on a MS SQL Server 2000 server when
attempting to use ODBC drivers from W2K workstations.
The MSSQLSERVER and SQLSERVERAGENT services both show DomainName
\Administrator under the "Logon under This Account" in the 'Logon' tab
in services.msc. The server name inside the SQL server are set to
mixed mode.
Am I correct in thinking that changing the password field shown in the
"Login under This account:DomainName\Administrator to match the new
domain administrator password will bring Joy?
Thanks!
Benoit
(Cross-posted to microsoft.public.sqlserver.server,
microsoft.public.sqlserver.setup, microsoft.public.sqlserver.odbc)
Are you saying that your SQL Server service is running under domain admin
user account? That is bad, that means SQL Server service can do anything
with the domain, which is really needed.
If the SQL Server service has to access something in the domain (say, you
added some extended procedures that require access files on other
computers), you can use a domain account that is only given proper
permission for just that purpose, using a domain admin account is an
overkill and dangerous.
With that said, the change you described should not affect how SQL Server is
accessed, as long as it still runs.
<bntgoogle@.yahoo.com> wrote in message
news:1194626641.221081.264340@.e34g2000pro.googlegr oups.com...
>A reality check please...
> After changing the domain administrator password, we are no longer
> able to connect to databases on a MS SQL Server 2000 server when
> attempting to use ODBC drivers from W2K workstations.
> The MSSQLSERVER and SQLSERVERAGENT services both show DomainName
> \Administrator under the "Logon under This Account" in the 'Logon' tab
> in services.msc. The server name inside the SQL server are set to
> mixed mode.
> Am I correct in thinking that changing the password field shown in the
> "Login under This account:DomainName\Administrator to match the new
> domain administrator password will bring Joy?
> Thanks!
> Benoit
> (Cross-posted to microsoft.public.sqlserver.server,
> microsoft.public.sqlserver.setup, microsoft.public.sqlserver.odbc)
>
|||Have both servers been rebooted since the domain name and password change?
Regards,
Jamie
"bntgoogle@.yahoo.com" wrote:

> A reality check please...
> After changing the domain administrator password, we are no longer
> able to connect to databases on a MS SQL Server 2000 server when
> attempting to use ODBC drivers from W2K workstations.
> The MSSQLSERVER and SQLSERVERAGENT services both show DomainName
> \Administrator under the "Logon under This Account" in the 'Logon' tab
> in services.msc. The server name inside the SQL server are set to
> mixed mode.
> Am I correct in thinking that changing the password field shown in the
> "Login under This account:DomainName\Administrator to match the new
> domain administrator password will bring Joy?
> Thanks!
> Benoit
> (Cross-posted to microsoft.public.sqlserver.server,
> microsoft.public.sqlserver.setup, microsoft.public.sqlserver.odbc)
>
|||Jamie
No, the SQL servers were not rebooted, a realization I had only after
we backed off and returned to the previous pwd. That seems to the
other likely reason why it breaks after this.
Put another way, my question is whether the username\password for the
account responsible for the server startup needs to be changed
*separately* after having changed the AD user password...
And oh yeah, I certainly know that is a bad user to use. That is why I
need to change it...
B
On Nov 9, 12:02 pm, thejamie <theja...@.discussions.microsoft.com>
wrote:[vbcol=seagreen]
> Have both servers been rebooted since the domain name and password change?
> --
> Regards,
> Jamie
> "bntgoo...@.yahoo.com" wrote:
>
>
>

domain administrator password and sql services startup

A reality check please...
After changing the domain administrator password, we are no longer
able to connect to databases on a MS SQL Server 2000 server when
attempting to use ODBC drivers from W2K workstations.
The MSSQLSERVER and SQLSERVERAGENT services both show DomainName
\Administrator under the "Logon under This Account" in the 'Logon' tab
in services.msc. The server name inside the SQL server are set to
mixed mode.
Am I correct in thinking that changing the password field shown in the
"Login under This account:DomainName\Administrator to match the new
domain administrator password will bring Joy?
Thanks!
Benoit
(Cross-posted to microsoft.public.sqlserver.server,
microsoft.public.sqlserver.setup, microsoft.public.sqlserver.odbc)Are you saying that your SQL Server service is running under domain admin
user account? That is bad, that means SQL Server service can do anything
with the domain, which is really needed.
If the SQL Server service has to access something in the domain (say, you
added some extended procedures that require access files on other
computers), you can use a domain account that is only given proper
permission for just that purpose, using a domain admin account is an
overkill and dangerous.
With that said, the change you described should not affect how SQL Server is
accessed, as long as it still runs.
<bntgoogle@.yahoo.com> wrote in message
news:1194626641.221081.264340@.e34g2000pro.googlegroups.com...
>A reality check please...
> After changing the domain administrator password, we are no longer
> able to connect to databases on a MS SQL Server 2000 server when
> attempting to use ODBC drivers from W2K workstations.
> The MSSQLSERVER and SQLSERVERAGENT services both show DomainName
> \Administrator under the "Logon under This Account" in the 'Logon' tab
> in services.msc. The server name inside the SQL server are set to
> mixed mode.
> Am I correct in thinking that changing the password field shown in the
> "Login under This account:DomainName\Administrator to match the new
> domain administrator password will bring Joy?
> Thanks!
> Benoit
> (Cross-posted to microsoft.public.sqlserver.server,
> microsoft.public.sqlserver.setup, microsoft.public.sqlserver.odbc)
>|||Have both servers been rebooted since the domain name and password change?
--
Regards,
Jamie
"bntgoogle@.yahoo.com" wrote:

> A reality check please...
> After changing the domain administrator password, we are no longer
> able to connect to databases on a MS SQL Server 2000 server when
> attempting to use ODBC drivers from W2K workstations.
> The MSSQLSERVER and SQLSERVERAGENT services both show DomainName
> \Administrator under the "Logon under This Account" in the 'Logon' tab
> in services.msc. The server name inside the SQL server are set to
> mixed mode.
> Am I correct in thinking that changing the password field shown in the
> "Login under This account:DomainName\Administrator to match the new
> domain administrator password will bring Joy?
> Thanks!
> Benoit
> (Cross-posted to microsoft.public.sqlserver.server,
> microsoft.public.sqlserver.setup, microsoft.public.sqlserver.odbc)
>|||Jamie
No, the SQL servers were not rebooted, a realization I had only after
we backed off and returned to the previous pwd. That seems to the
other likely reason why it breaks after this.
Put another way, my question is whether the username\password for the
account responsible for the server startup needs to be changed
*separately* after having changed the AD user password...
And oh yeah, I certainly know that is a bad user to use. That is why I
need to change it...
B
On Nov 9, 12:02 pm, thejamie <theja...@.discussions.microsoft.com>
wrote:[vbcol=seagreen]
> Have both servers been rebooted since the domain name and password change?
> --
> Regards,
> Jamie
> "bntgoo...@.yahoo.com" wrote:
>
>
>
>
>
>

domain administrator password and sql services startup

A reality check please...
After changing the domain administrator password, we are no longer
able to connect to databases on a MS SQL Server 2000 server when
attempting to use ODBC drivers from W2K workstations.
The MSSQLSERVER and SQLSERVERAGENT services both show DomainName
\Administrator under the "Logon under This Account" in the 'Logon' tab
in services.msc. The server name inside the SQL server are set to
mixed mode.
Am I correct in thinking that changing the password field shown in the
"Login under This account:DomainName\Administrator to match the new
domain administrator password will bring Joy?
Thanks!
Benoit
(Cross-posted to microsoft.public.sqlserver.server,
microsoft.public.sqlserver.setup, microsoft.public.sqlserver.odbc)Hello,
Yes, if the Windows account used by the SQL Server services has a new
password you should update it here or by using Enterprise Manager.
Also, it would be better if you use a dedicated Windows account for SQL
Server instead of the domain administrator account.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"bntgoogle@.yahoo.com" wrote:

> A reality check please...
> After changing the domain administrator password, we are no longer
> able to connect to databases on a MS SQL Server 2000 server when
> attempting to use ODBC drivers from W2K workstations.
> The MSSQLSERVER and SQLSERVERAGENT services both show DomainName
> \Administrator under the "Logon under This Account" in the 'Logon' tab
> in services.msc. The server name inside the SQL server are set to
> mixed mode.
> Am I correct in thinking that changing the password field shown in the
> "Login under This account:DomainName\Administrator to match the new
> domain administrator password will bring Joy?
> Thanks!
> Benoit
> (Cross-posted to microsoft.public.sqlserver.server,
> microsoft.public.sqlserver.setup, microsoft.public.sqlserver.odbc)
>

domain administrator password and sql services startup

A reality check please...
After changing the domain administrator password, we are no longer
able to connect to databases on a MS SQL Server 2000 server when
attempting to use ODBC drivers from W2K workstations.
The MSSQLSERVER and SQLSERVERAGENT services both show DomainName
\Administrator under the "Logon under This Account" in the 'Logon' tab
in services.msc. The server name inside the SQL server are set to
mixed mode.
Am I correct in thinking that changing the password field shown in the
"Login under This account:DomainName\Administrator to match the new
domain administrator password will bring Joy?
Thanks!
Benoit
(Cross-posted to microsoft.public.sqlserver.server,
microsoft.public.sqlserver.setup, microsoft.public.sqlserver.odbc)
Hello,
Yes, if the Windows account used by the SQL Server services has a new
password you should update it here or by using Enterprise Manager.
Also, it would be better if you use a dedicated Windows account for SQL
Server instead of the domain administrator account.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"bntgoogle@.yahoo.com" wrote:

> A reality check please...
> After changing the domain administrator password, we are no longer
> able to connect to databases on a MS SQL Server 2000 server when
> attempting to use ODBC drivers from W2K workstations.
> The MSSQLSERVER and SQLSERVERAGENT services both show DomainName
> \Administrator under the "Logon under This Account" in the 'Logon' tab
> in services.msc. The server name inside the SQL server are set to
> mixed mode.
> Am I correct in thinking that changing the password field shown in the
> "Login under This account:DomainName\Administrator to match the new
> domain administrator password will bring Joy?
> Thanks!
> Benoit
> (Cross-posted to microsoft.public.sqlserver.server,
> microsoft.public.sqlserver.setup, microsoft.public.sqlserver.odbc)
>

domain administrator password and sql services startup

A reality check please...
After changing the domain administrator password, we are no longer
able to connect to databases on a MS SQL Server 2000 server when
attempting to use ODBC drivers from W2K workstations.
The MSSQLSERVER and SQLSERVERAGENT services both show DomainName
\Administrator under the "Logon under This Account" in the 'Logon' tab
in services.msc. The server name inside the SQL server are set to
mixed mode.
Am I correct in thinking that changing the password field shown in the
"Login under This account:DomainName\Administrator to match the new
domain administrator password will bring Joy?
Thanks!
Benoit
(Cross-posted to microsoft.public.sqlserver.server,
microsoft.public.sqlserver.setup, microsoft.public.sqlserver.odbc)
Are you saying that your SQL Server service is running under domain admin
user account? That is bad, that means SQL Server service can do anything
with the domain, which is really needed.
If the SQL Server service has to access something in the domain (say, you
added some extended procedures that require access files on other
computers), you can use a domain account that is only given proper
permission for just that purpose, using a domain admin account is an
overkill and dangerous.
With that said, the change you described should not affect how SQL Server is
accessed, as long as it still runs.
<bntgoogle@.yahoo.com> wrote in message
news:1194626641.221081.264340@.e34g2000pro.googlegr oups.com...
>A reality check please...
> After changing the domain administrator password, we are no longer
> able to connect to databases on a MS SQL Server 2000 server when
> attempting to use ODBC drivers from W2K workstations.
> The MSSQLSERVER and SQLSERVERAGENT services both show DomainName
> \Administrator under the "Logon under This Account" in the 'Logon' tab
> in services.msc. The server name inside the SQL server are set to
> mixed mode.
> Am I correct in thinking that changing the password field shown in the
> "Login under This account:DomainName\Administrator to match the new
> domain administrator password will bring Joy?
> Thanks!
> Benoit
> (Cross-posted to microsoft.public.sqlserver.server,
> microsoft.public.sqlserver.setup, microsoft.public.sqlserver.odbc)
>
|||Have both servers been rebooted since the domain name and password change?
Regards,
Jamie
"bntgoogle@.yahoo.com" wrote:

> A reality check please...
> After changing the domain administrator password, we are no longer
> able to connect to databases on a MS SQL Server 2000 server when
> attempting to use ODBC drivers from W2K workstations.
> The MSSQLSERVER and SQLSERVERAGENT services both show DomainName
> \Administrator under the "Logon under This Account" in the 'Logon' tab
> in services.msc. The server name inside the SQL server are set to
> mixed mode.
> Am I correct in thinking that changing the password field shown in the
> "Login under This account:DomainName\Administrator to match the new
> domain administrator password will bring Joy?
> Thanks!
> Benoit
> (Cross-posted to microsoft.public.sqlserver.server,
> microsoft.public.sqlserver.setup, microsoft.public.sqlserver.odbc)
>
|||Jamie
No, the SQL servers were not rebooted, a realization I had only after
we backed off and returned to the previous pwd. That seems to the
other likely reason why it breaks after this.
Put another way, my question is whether the username\password for the
account responsible for the server startup needs to be changed
*separately* after having changed the AD user password...
And oh yeah, I certainly know that is a bad user to use. That is why I
need to change it...
B
On Nov 9, 12:02 pm, thejamie <theja...@.discussions.microsoft.com>
wrote:[vbcol=seagreen]
> Have both servers been rebooted since the domain name and password change?
> --
> Regards,
> Jamie
> "bntgoo...@.yahoo.com" wrote:
>
>
>

domain administrator password and sql services startup

A reality check please...
After changing the domain administrator password, we are no longer
able to connect to databases on a MS SQL Server 2000 server when
attempting to use ODBC drivers from W2K workstations.
The MSSQLSERVER and SQLSERVERAGENT services both show DomainName
\Administrator under the "Logon under This Account" in the 'Logon' tab
in services.msc. The server name inside the SQL server are set to
mixed mode.
Am I correct in thinking that changing the password field shown in the
"Login under This account:DomainName\Administrator to match the new
domain administrator password will bring Joy?
Thanks!
Benoit
(Cross-posted to microsoft.public.sqlserver.server,
microsoft.public.sqlserver.setup, microsoft.public.sqlserver.odbc)Hello,
Yes, if the Windows account used by the SQL Server services has a new
password you should update it here or by using Enterprise Manager.
Also, it would be better if you use a dedicated Windows account for SQL
Server instead of the domain administrator account.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"bntgoogle@.yahoo.com" wrote:
> A reality check please...
> After changing the domain administrator password, we are no longer
> able to connect to databases on a MS SQL Server 2000 server when
> attempting to use ODBC drivers from W2K workstations.
> The MSSQLSERVER and SQLSERVERAGENT services both show DomainName
> \Administrator under the "Logon under This Account" in the 'Logon' tab
> in services.msc. The server name inside the SQL server are set to
> mixed mode.
> Am I correct in thinking that changing the password field shown in the
> "Login under This account:DomainName\Administrator to match the new
> domain administrator password will bring Joy?
> Thanks!
> Benoit
> (Cross-posted to microsoft.public.sqlserver.server,
> microsoft.public.sqlserver.setup, microsoft.public.sqlserver.odbc)
>

domain administrator password and sql services startup

A reality check please...
After changing the domain administrator password, we are no longer
able to connect to databases on a MS SQL Server 2000 server when
attempting to use ODBC drivers from W2K workstations.
The MSSQLSERVER and SQLSERVERAGENT services both show DomainName
\Administrator under the "Logon under This Account" in the 'Logon' tab
in services.msc. The server name inside the SQL server are set to
mixed mode.
Am I correct in thinking that changing the password field shown in the
"Login under This account:DomainName\Administrator to match the new
domain administrator password will bring Joy?
Thanks!
Benoit
(Cross-posted to microsoft.public.sqlserver.server,
microsoft.public.sqlserver.setup, microsoft.public.sqlserver.odbc)Are you saying that your SQL Server service is running under domain admin
user account? That is bad, that means SQL Server service can do anything
with the domain, which is really needed.
If the SQL Server service has to access something in the domain (say, you
added some extended procedures that require access files on other
computers), you can use a domain account that is only given proper
permission for just that purpose, using a domain admin account is an
overkill and dangerous.
With that said, the change you described should not affect how SQL Server is
accessed, as long as it still runs.
<bntgoogle@.yahoo.com> wrote in message
news:1194626641.221081.264340@.e34g2000pro.googlegroups.com...
>A reality check please...
> After changing the domain administrator password, we are no longer
> able to connect to databases on a MS SQL Server 2000 server when
> attempting to use ODBC drivers from W2K workstations.
> The MSSQLSERVER and SQLSERVERAGENT services both show DomainName
> \Administrator under the "Logon under This Account" in the 'Logon' tab
> in services.msc. The server name inside the SQL server are set to
> mixed mode.
> Am I correct in thinking that changing the password field shown in the
> "Login under This account:DomainName\Administrator to match the new
> domain administrator password will bring Joy?
> Thanks!
> Benoit
> (Cross-posted to microsoft.public.sqlserver.server,
> microsoft.public.sqlserver.setup, microsoft.public.sqlserver.odbc)
>|||Have both servers been rebooted since the domain name and password change?
--
Regards,
Jamie
"bntgoogle@.yahoo.com" wrote:
> A reality check please...
> After changing the domain administrator password, we are no longer
> able to connect to databases on a MS SQL Server 2000 server when
> attempting to use ODBC drivers from W2K workstations.
> The MSSQLSERVER and SQLSERVERAGENT services both show DomainName
> \Administrator under the "Logon under This Account" in the 'Logon' tab
> in services.msc. The server name inside the SQL server are set to
> mixed mode.
> Am I correct in thinking that changing the password field shown in the
> "Login under This account:DomainName\Administrator to match the new
> domain administrator password will bring Joy?
> Thanks!
> Benoit
> (Cross-posted to microsoft.public.sqlserver.server,
> microsoft.public.sqlserver.setup, microsoft.public.sqlserver.odbc)
>|||Jamie
No, the SQL servers were not rebooted, a realization I had only after
we backed off and returned to the previous pwd. That seems to the
other likely reason why it breaks after this.
Put another way, my question is whether the username\password for the
account responsible for the server startup needs to be changed
*separately* after having changed the AD user password...
And oh yeah, I certainly know that is a bad user to use. That is why I
need to change it... :)
B
On Nov 9, 12:02 pm, thejamie <theja...@.discussions.microsoft.com>
wrote:
> Have both servers been rebooted since the domain name and password change?
> --
> Regards,
> Jamie
> "bntgoo...@.yahoo.com" wrote:
> > A reality check please...
> > After changing the domain administrator password, we are no longer
> > able to connect to databases on a MS SQL Server 2000 server when
> > attempting to use ODBC drivers from W2K workstations.
> > The MSSQLSERVER and SQLSERVERAGENT services both show DomainName
> > \Administrator under the "Logon under This Account" in the 'Logon' tab
> > in services.msc. The server name inside the SQL server are set to
> > mixed mode.
> > Am I correct in thinking that changing the password field shown in the
> > "Login under This account:DomainName\Administrator to match the new
> > domain administrator password will bring Joy?
> > Thanks!
> > Benoit
> > (Cross-posted to microsoft.public.sqlserver.server,
> > microsoft.public.sqlserver.setup, microsoft.public.sqlserver.odbc)

Domain Admin

This is a quick one: does the domain account that is installing SQL Server on
a cluster need to also be a domain administrator? If it weren't, would that
cause the SQL insatall to fail?
Thanks again!
NO!!!!! Make it a Domain User only, then add it to the local Administrators
group on each node.
Cheers,
Rod
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering
http://msmvps.com/clustering - Blog
"A. Robinson" <ARobinson@.discussions.microsoft.com> wrote in message
news:EDBD5BC8-5C0F-4DEF-AE89-F1FDB069C4F3@.microsoft.com...
> This is a quick one: does the domain account that is installing SQL Server
> on
> a cluster need to also be a domain administrator? If it weren't, would
> that
> cause the SQL insatall to fail?
> Thanks again!
>
|||Didn't think so...I now have no idea what's going on with this install.
I'm getting a PATH SPECIFIED IN COMMAND IS NOT VALID:
\\HMS10NK03\ADMIN$\HMS10NK03_MSSQLSERVER.ISS That file doesn't exist in the
directory anywhere...
That path is just the Windows directory. The user I'm installing under is a
local admin and also has explicit rights to the directory/share.
The install goes for about 20-30 minutews and then get the infamous CAN'T
PERFORM OPERATIONS ON CLUSTER (whatever). When I go out to the Windows
directory, there's no SQLSTP.LOG file at all!!
We're not utilizing MSDTC anywhere so I didn't bother setting up a
group/resource for it. All communications between nodes/shared disks are good.
If anyone can shed any light, I would really appreciate it. If logs would
help, let me know which ones should be looked at (there aren't a whole lot to
choose from). I've included the SETUP.ISS
[InstallShield Silent]
Version=v5.00.000
File=Response File
[File Transfer]
OverwriteReadOnly=NoToAll
[DlgOrder]
Dlg0=SdWelcome-0
Count=19
Dlg1=DlgMachine-0
Dlg2=DlgInstallMode-0
Dlg3=SdRegisterUser-0
Dlg4=SdLicense-0
Dlg5=DlgVirtServer-0
Dlg6=DlgDiskGroups-0
Dlg7=DlgClusterDef-0
Dlg8=DlgAccount-0
Dlg9=DlgClientServer-0
Dlg10=DlgInstanceName-0
Dlg11=SetupTypeSQL-0
Dlg12=SdRemoteInfo-0
Dlg13=DlgServices-0
Dlg14=DlgSQLSecurity-0
Dlg15=DlgCollation-0
Dlg16=DlgServerNetwork-0
Dlg17=SdStartCopy-0
Dlg18=SdFinish-0
[SdWelcome-0]
Result=1
[DlgMachine-0]
Name=HMS10NK04
Type=268435466
Result=1
[DlgInstallMode-0]
Type=1
Result=1
[SdRegisterUser-0]
szName=Hoffman
Result=1
[SdLicense-0]
Result=1
[DlgVirtServer-0]
VirtServerName=HMS10NK04
IpAddresses=10.150.128.114,255.255.255.0,Public - 10.150.128.112
Result=0
[DlgDiskGroups-0]
GroupName=SQLServer
Result=1
[DlgClusterDef-0]
VirtServerName=HMS10NK04
nNumNodes=2
Result=1
ClusterPrefOwners=HMS10NK03,HMS10NK02
[DlgAccount-0]
Domain=HOFFMAN
DomainAcct=MSOCLUSTER
DomainPwd=154526877651e5de852d536c6f8f0889
Result=1
[DlgClientServer-0]
Type=2
Result=1
[DlgInstanceName-0]
InstanceName=MSSQLSERVER
Result=1
[SetupTypeSQL-0]
szDir=C:\Program Files\Microsoft SQL Server
Result=301
szDataDir=S:\Program Files\Microsoft SQL Server
SharedDataDir=S:\Program Files\Microsoft SQL Server
[SdRemoteInfo-0]
svEdit1=MSOCLUSTER
svEdit2=154526877651e5de852d536c6f8f0889
svEdit3=HOFFMAN
svEdit4=HMS10NK04
svEdit5=\\HMS10NK04\C$\Program Files\Microsoft SQL Server
svEdit6=\\HMS10NK03\Z$\x86\setup\
Result=1
[DlgServices-0]
Local-Domain=61680
AutoStart=0
SQLDomain=HOFFMAN
SQLDomainAcct=MSOCLUSTER
SQLDomainPwd=154526877651e5de852d536c6f8f0889
AgtDomain=HOFFMAN
AgtDomainAcct=MSOCLUSTER
AgtDomainPwd=154526877651e5de852d536c6f8f0889
Result=1
[DlgSQLSecurity-0]
LoginMode=2
szPwd=086483159a17f2fb6d
Result=1
[DlgCollation-0]
collation_name=SQL_Latin1_General_CP1_CI_AS
Result=1
[DlgServerNetwork-0]
NetworkLibs=255
TCPPort=1433
TCPPrxy=Default
NMPPipeName=\\.\pipe\sql\query
Result=1
[SdStartCopy-0]
Result=1
[License]
LicenseMode=PERDEVICE
LicenseLimit=4
[SdFinish-0]
Result=1
bOpt1=0
bOpt2=0
"Rodney R. Fournier [MVP]" wrote:

> NO!!!!! Make it a Domain User only, then add it to the local Administrators
> group on each node.
> Cheers,
> Rod
> MVP - Windows Server - Clustering
> http://www.nw-america.com - Clustering
> http://msmvps.com/clustering - Blog
> "A. Robinson" <ARobinson@.discussions.microsoft.com> wrote in message
> news:EDBD5BC8-5C0F-4DEF-AE89-F1FDB069C4F3@.microsoft.com...
>
>
|||Have your tried copying the SQL install files locally and running from
there?
Cheers,
Rod
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering
http://msmvps.com/clustering - Blog
"A. Robinson" <ARobinson@.discussions.microsoft.com> wrote in message
news:C606061F-CB5E-48AF-A1D8-81E6F2FFF01F@.microsoft.com...[vbcol=seagreen]
> Didn't think so...I now have no idea what's going on with this install.
> I'm getting a PATH SPECIFIED IN COMMAND IS NOT VALID:
> \\HMS10NK03\ADMIN$\HMS10NK03_MSSQLSERVER.ISS That file doesn't exist in
> the
> directory anywhere...
> That path is just the Windows directory. The user I'm installing under is
> a
> local admin and also has explicit rights to the directory/share.
> The install goes for about 20-30 minutews and then get the infamous CAN'T
> PERFORM OPERATIONS ON CLUSTER (whatever). When I go out to the Windows
> directory, there's no SQLSTP.LOG file at all!!
> We're not utilizing MSDTC anywhere so I didn't bother setting up a
> group/resource for it. All communications between nodes/shared disks are
> good.
> If anyone can shed any light, I would really appreciate it. If logs would
> help, let me know which ones should be looked at (there aren't a whole lot
> to
> choose from). I've included the SETUP.ISS
> [InstallShield Silent]
> Version=v5.00.000
> File=Response File
> [File Transfer]
> OverwriteReadOnly=NoToAll
> [DlgOrder]
> Dlg0=SdWelcome-0
> Count=19
> Dlg1=DlgMachine-0
> Dlg2=DlgInstallMode-0
> Dlg3=SdRegisterUser-0
> Dlg4=SdLicense-0
> Dlg5=DlgVirtServer-0
> Dlg6=DlgDiskGroups-0
> Dlg7=DlgClusterDef-0
> Dlg8=DlgAccount-0
> Dlg9=DlgClientServer-0
> Dlg10=DlgInstanceName-0
> Dlg11=SetupTypeSQL-0
> Dlg12=SdRemoteInfo-0
> Dlg13=DlgServices-0
> Dlg14=DlgSQLSecurity-0
> Dlg15=DlgCollation-0
> Dlg16=DlgServerNetwork-0
> Dlg17=SdStartCopy-0
> Dlg18=SdFinish-0
> [SdWelcome-0]
> Result=1
> [DlgMachine-0]
> Name=HMS10NK04
> Type=268435466
> Result=1
> [DlgInstallMode-0]
> Type=1
> Result=1
> [SdRegisterUser-0]
> szName=Hoffman
> Result=1
> [SdLicense-0]
> Result=1
> [DlgVirtServer-0]
> VirtServerName=HMS10NK04
> IpAddresses=10.150.128.114,255.255.255.0,Public - 10.150.128.112
> Result=0
> [DlgDiskGroups-0]
> GroupName=SQLServer
> Result=1
> [DlgClusterDef-0]
> VirtServerName=HMS10NK04
> nNumNodes=2
> Result=1
> ClusterPrefOwners=HMS10NK03,HMS10NK02
> [DlgAccount-0]
> Domain=HOFFMAN
> DomainAcct=MSOCLUSTER
> DomainPwd=154526877651e5de852d536c6f8f0889
> Result=1
> [DlgClientServer-0]
> Type=2
> Result=1
> [DlgInstanceName-0]
> InstanceName=MSSQLSERVER
> Result=1
> [SetupTypeSQL-0]
> szDir=C:\Program Files\Microsoft SQL Server
> Result=301
> szDataDir=S:\Program Files\Microsoft SQL Server
> SharedDataDir=S:\Program Files\Microsoft SQL Server
> [SdRemoteInfo-0]
> svEdit1=MSOCLUSTER
> svEdit2=154526877651e5de852d536c6f8f0889
> svEdit3=HOFFMAN
> svEdit4=HMS10NK04
> svEdit5=\\HMS10NK04\C$\Program Files\Microsoft SQL Server
> svEdit6=\\HMS10NK03\Z$\x86\setup\
> Result=1
> [DlgServices-0]
> Local-Domain=61680
> AutoStart=0
> SQLDomain=HOFFMAN
> SQLDomainAcct=MSOCLUSTER
> SQLDomainPwd=154526877651e5de852d536c6f8f0889
> AgtDomain=HOFFMAN
> AgtDomainAcct=MSOCLUSTER
> AgtDomainPwd=154526877651e5de852d536c6f8f0889
> Result=1
> [DlgSQLSecurity-0]
> LoginMode=2
> szPwd=086483159a17f2fb6d
> Result=1
> [DlgCollation-0]
> collation_name=SQL_Latin1_General_CP1_CI_AS
> Result=1
> [DlgServerNetwork-0]
> NetworkLibs=255
> TCPPort=1433
> TCPPrxy=Default
> NMPPipeName=\\.\pipe\sql\query
> Result=1
> [SdStartCopy-0]
> Result=1
> [License]
> LicenseMode=PERDEVICE
> LicenseLimit=4
> [SdFinish-0]
> Result=1
> bOpt1=0
> bOpt2=0
>
> "Rodney R. Fournier [MVP]" wrote:
|||THanks again, Rod - I'll try that now.
In the meantime, have you ever seen anything like this:
During the SQL Server install, I am receiving the following message: PATH
SPECIFIED IN COMMAND IS NOT VALID:
\\HMS10NK03\ADMIN$\HMS10NK03_MSSQLSERVER.ISS This path is the C:\WINDOWS
directory. The login being used to install SQL Server is a local admin on
both nodes of the cluster and the local admin group has full rights to the
directory. It's working because the user is writing various other logs.
There's plenty of space on the drive as well...
"Rodney R. Fournier [MVP]" wrote:

> Have your tried copying the SQL install files locally and running from
> there?
> Cheers,
> Rod
> MVP - Windows Server - Clustering
> http://www.nw-america.com - Clustering
> http://msmvps.com/clustering - Blog
> "A. Robinson" <ARobinson@.discussions.microsoft.com> wrote in message
> news:C606061F-CB5E-48AF-A1D8-81E6F2FFF01F@.microsoft.com...
>
>
|||Make sure you have logged in to each node using the install and service
accounts before starting the installation. That will guarantee the account
profile gets set up correctly on each machine Also, check your system TMP
and TEMP variables to make sure they point to valid paths on all nodes.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"A. Robinson" <ARobinson@.discussions.microsoft.com> wrote in message
news:9274C646-FBC5-4949-A089-CAB3C3E63786@.microsoft.com...[vbcol=seagreen]
> THanks again, Rod - I'll try that now.
> In the meantime, have you ever seen anything like this:
> During the SQL Server install, I am receiving the following message: PATH
> SPECIFIED IN COMMAND IS NOT VALID:
> \\HMS10NK03\ADMIN$\HMS10NK03_MSSQLSERVER.ISS This path is the C:\WINDOWS
> directory. The login being used to install SQL Server is a local admin on
> both nodes of the cluster and the local admin group has full rights to the
> directory. It's working because the user is writing various other logs.
> There's plenty of space on the drive as well...
>
> "Rodney R. Fournier [MVP]" wrote:
install.[vbcol=seagreen]
in[vbcol=seagreen]
is[vbcol=seagreen]
CAN'T[vbcol=seagreen]
are[vbcol=seagreen]
would[vbcol=seagreen]
lot[vbcol=seagreen]
would[vbcol=seagreen]
|||the ADMIN$ share probably does not have the correct share permissions for
the account you are using to look at it
"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:#1nqZ5kJFHA.3492@.TK2MSFTNGP10.phx.gbl...
> Make sure you have logged in to each node using the install and service
> accounts before starting the installation. That will guarantee the
account[vbcol=seagreen]
> profile gets set up correctly on each machine Also, check your system TMP
> and TEMP variables to make sure they point to valid paths on all nodes.
> --
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> I support the Professional Association for SQL Server
> www.sqlpass.org
> "A. Robinson" <ARobinson@.discussions.microsoft.com> wrote in message
> news:9274C646-FBC5-4949-A089-CAB3C3E63786@.microsoft.com...
PATH[vbcol=seagreen]
C:\WINDOWS[vbcol=seagreen]
on[vbcol=seagreen]
the[vbcol=seagreen]
> install.
exist[vbcol=seagreen]
> in
under[vbcol=seagreen]
> is
> CAN'T
Windows[vbcol=seagreen]
> are
> would
whole[vbcol=seagreen]
> lot
message[vbcol=seagreen]
SQL
> would
>