Download December CTP?

I've got an old package that I need to take a look at in SSIS, but it was built in the December CTP. Is there anywhere I can download this version?
You should be able to open it in the latest build. Did you try?|||Yep, I tried it with the latest CTP and it opened OK.

Thanks Kirk!

Domain group logins failing on SQL 2k5 workgroup

This question is regarding a brand new out-of-the-box SQL Server 2005 Workgroup Edition install. The old SQL Server 2000 server is working properly with regard to the issue we're having:
We are using Windows Authentication, and have created SQL logins for about

40 different groups on our domain. We've given those logins the appropriate

permissions on the databases they're supposed to be able to access.

The SQL Server is not a domain controller, but is a member of the domain, and domain logins do work for Windows-login purposes on this box.
The problem is that when users try to connect to the SQL server, they are denied access. An error 18456 is thrown, and logged in the Application event log

stating "Login failed for user OURDOMAIN\theuser" (example values). The

domain user is properly a member of group added as a login to SQL Server, and we've

confirmed that there are not conflicting permissions that would deny those

users access via another route. These same groups are working fine on the SQL Server 2000 box.
This is only a problem for domain-based groups. If we create a local group

on the SQL server machine, through Computer Management -> Local Users and

Groups, then make the same domain users a member of THAT group, and finally then

follow the same process to add that local group to SQL Server Logins and set

the database privileges, it works!!
Our group memberships change frequently, and are used for a lot more than

just SQL server permissions. So, using local groups and maintaining

membership in both places is not really feasible. Any ideas why a local

machine group containing domain user accounts would work fine, but a domain

group containing the same accounts would not?
Thanks in advance.
Hi,

see if the default database defined for the users / groups ius available and they are granted access to the database. If not they will be denied access to the server and will get the error message posted by you. Did you try to create a single Windows and login with this user ?

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de|||Single user: Yes. Creating individual logins for domain users works fine. It is only logins for domain groups that are not working.

Default database: The users are connecting via ODBC connections, and the default database is set correctly.

It doesn't seem to be related to any database selection issues at all. Within a single database, if we grant access to the individual user account, or a local machine group that the user is a part of, everything works fine. Grant them access via a domain group, and it denies login. This is not something we've encountered before, and is making me wonder if there is some weird, poorly-documented restriction in the Workgroup Edition...|||

Please post the error as it is printed in the errorlog file of SQL Server (the ones under MSSQL\...\LOG\ERRORLOG*). Post both the error messages and the error numbers and states - the states are important.

Thanks
Laurentiu

|||(Domain name/IP munged for privacy reasons. Can send via private message if required for some reason.)

With group OURDOMAIN\SecGroupA created on the domain controller, and user 'kswain' made a member of the group. We create a SQL Server login for OURDOMAIN\SecGroupA and get:

2006-12-27 10:45:02.50 Logon Error: 18456, Severity: 14, State: 11.
2006-12-27 10:45:02.50 Logon Login failed for user 'OURDOMAIN\kswain'. [CLIENT: xxx.xxx.xxx.xxx]

With local group TestLocalGroup created on the SQL Server machine, and user 'OURDOMAIN\kswain' added as a member: We create a SQL Server login for SERVERMACHINE\TestLocalGroup using the same process as previously, and it works fine. We don't even have to log the end-user account out of the application... it works as soon as we authorize the local group.|||

Hi,

Does this error comes when you access from your Application or via Query Analyzer ? Are you able to login via Query Analyzer?

What application you are running !? A web application ? Ensure IIS Permission is also properly set refer below KB

http://support.microsoft.com/kb/316989/

What about connection string in your application ?

Hemantgiri S. Goswami

|||The login failure occurs both from the application and from Query Analyzer using any non-Administrator account.

Our testbed application at the moment is actually just an Access database, using the built-in Windows SQL Server ODBC driver, set up as a Machine DSN. When our main app didn't work, we created the simplest method we could think of to try and connect. We are not using IIS for this at all. We know the DSN itself is set up correctly since it works if the user is explicitly added, or is part of a SQL Server machine-local group.

--
One additional thing we've discovered in the last 24 hours. It still does NOT work if you add a domain group to a local group. So the issue seems to be one of domain group membership resolution. In other words, if we authorize SQLServer\LocalGroupA:

* If OURDOMAIN\userA is a member of SQLServer\LocalGroupA, OURDOMAIN\userA login => OK

* If OURDOMAIN\userA is a member of OURDOMAIN\DomainGroupA, and OURDOMAIN\DomainGroupA is a member of SQLServer\LocalGroupA, OURDOMAIN\userA login => FAIL!

Other thoughts we're having that might be somehow relevant, but we can't seem to get around:

1) The domain is mixed Win2000 and Win2003. The SQL Server 2k5 is running on a Win2003 machine that is not a domain controller, but is a domain member.

2) Our AD domain name has a hyphen in it, both in NetBIOS and FQDN (i.e. OUR-DOMAIN and cleveland.our-domain.local)

3) The non-administrative users are accessing the application server via Terminal Services.

None of the above should make a difference (and don't have any problems with SQL Server 2000), but we're really grasping at straws at this point...|||

Can you see if LookupAccountName works for the group name? If you have a small application called name2sid, you could use it to check this. Or you could use something similar to my CLR function from http://blogs.msdn.com/lcris/archive/2005/09/26/474202.aspx.

If this function works ok, then I suggest to open a report on the site indicated in the sticky thread at the top of this forum. You can start the server with the -y18456 parameter, to have it generate a memory dump, and you can attach the dump to the report.

Thanks
Laurentiu

|||I don't have name2sid, but I have the SysInternals "psGetSid" utility, which should do the same thing. Run against OURDOMAIN\TestGroupA, it returns a good SID, so that much is working. If your function or name2sid does something different than this utility, to your knowledge, please let me know and I can try to implement that instead.

I'm not familiar with the -y18456 parameter. I just restarted the SQL Server service with that flag included in the Startup Parameters, but don't see a dump anywhere, or anything especially instructive in the event log. Can you tell me what I should be looking for after restarting with that flag? Once I can find that, I'll open a report on the Connect site. Thanks!|||Please disregard previous request -- I see that it only outputs dumps when that specific error is thrown. Got it, and attaching it to a Connect bug now. Thanks!|||Just for closure on this thread, this issue has been moved to a Connect feedback/bug report. ID is 248615 and can be found here:

https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=248615|||

Hi,

Did you find a fix for this? I think we're having the same problem. I talked to a consultant who thought it was something with our domain since we were running windows 2000 and didnt have the windows DNS running as part of our domain. But everything was working except sql server so I should have known better. So we upgraded our domain controller and spent all kinds of money and it still doesn't work!! Please let me know if you figured out how to fix this!! None of our AD groups are working as logins. Only users and groups on the sql server machine.

Bob Coleman

|||No fix or workaround has been identified yet. Nobody at Microsoft has tagged the Connect bug referenced above, if it has even been reviewed yet. I'm trying to be patient, figuring that people were on vacation over the holidays.

At the moment, we're just maintaining machine-local accounts with the appropriate domain users. Hopefully we'll get some kind of response shortly!|||

We have received your feedback report. When we'll have an update on this issue, we'll update the report.

I am not familiar with the PsSid tool - could you point me to the link from which you downloaded it?

The -y argument can be used with any error number, to make the server produce a dump whenever the error is raised.

Thanks
Laurentiu

|||Certainly! psGetSid was referenced on this page: http://www.microsoft.com/technet/sysinternals/utilities/psgetsid.mspx

It's part of the SysInternals command-line suite that MS acquired earlier this year. Nifty stuff.

Thanks!

Domain group logins failing on SQL 2k5 workgroup

This question is regarding a brand new out-of-the-box SQL Server 2005 Workgroup Edition install. The old SQL Server 2000 server is working properly with regard to the issue we're having:
We are using Windows Authentication, and have created SQL logins for about

40 different groups on our domain. We've given those logins the appropriate

permissions on the databases they're supposed to be able to access.

The SQL Server is not a domain controller, but is a member of the domain, and domain logins do work for Windows-login purposes on this box.
The problem is that when users try to connect to the SQL server, they are denied access. An error 18456 is thrown, and logged in the Application event log

stating "Login failed for user OURDOMAIN\theuser" (example values). The

domain user is properly a member of group added as a login to SQL Server, and we've

confirmed that there are not conflicting permissions that would deny those

users access via another route. These same groups are working fine on the SQL Server 2000 box.
This is only a problem for domain-based groups. If we create a local group

on the SQL server machine, through Computer Management -> Local Users and

Groups, then make the same domain users a member of THAT group, and finally then

follow the same process to add that local group to SQL Server Logins and set

the database privileges, it works!!
Our group memberships change frequently, and are used for a lot more than

just SQL server permissions. So, using local groups and maintaining

membership in both places is not really feasible. Any ideas why a local

machine group containing domain user accounts would work fine, but a domain

group containing the same accounts would not?
Thanks in advance.
Hi,

see if the default database defined for the users / groups ius available and they are granted access to the database. If not they will be denied access to the server and will get the error message posted by you. Did you try to create a single Windows and login with this user ?

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de|||Single user: Yes. Creating individual logins for domain users works fine. It is only logins for domain groups that are not working.

Default database: The users are connecting via ODBC connections, and the default database is set correctly.

It doesn't seem to be related to any database selection issues at all. Within a single database, if we grant access to the individual user account, or a local machine group that the user is a part of, everything works fine. Grant them access via a domain group, and it denies login. This is not something we've encountered before, and is making me wonder if there is some weird, poorly-documented restriction in the Workgroup Edition...|||

Please post the error as it is printed in the errorlog file of SQL Server (the ones under MSSQL\...\LOG\ERRORLOG*). Post both the error messages and the error numbers and states - the states are important.

Thanks
Laurentiu

|||(Domain name/IP munged for privacy reasons. Can send via private message if required for some reason.)

With group OURDOMAIN\SecGroupA created on the domain controller, and user 'kswain' made a member of the group. We create a SQL Server login for OURDOMAIN\SecGroupA and get:

2006-12-27 10:45:02.50 Logon Error: 18456, Severity: 14, State: 11.
2006-12-27 10:45:02.50 Logon Login failed for user 'OURDOMAIN\kswain'. [CLIENT: xxx.xxx.xxx.xxx]

With local group TestLocalGroup created on the SQL Server machine, and user 'OURDOMAIN\kswain' added as a member: We create a SQL Server login for SERVERMACHINE\TestLocalGroup using the same process as previously, and it works fine. We don't even have to log the end-user account out of the application... it works as soon as we authorize the local group.|||

Hi,

Does this error comes when you access from your Application or via Query Analyzer ? Are you able to login via Query Analyzer?

What application you are running !? A web application ? Ensure IIS Permission is also properly set refer below KB

http://support.microsoft.com/kb/316989/

What about connection string in your application ?

Hemantgiri S. Goswami

|||The login failure occurs both from the application and from Query Analyzer using any non-Administrator account.

Our testbed application at the moment is actually just an Access database, using the built-in Windows SQL Server ODBC driver, set up as a Machine DSN. When our main app didn't work, we created the simplest method we could think of to try and connect. We are not using IIS for this at all. We know the DSN itself is set up correctly since it works if the user is explicitly added, or is part of a SQL Server machine-local group.

--
One additional thing we've discovered in the last 24 hours. It still does NOT work if you add a domain group to a local group. So the issue seems to be one of domain group membership resolution. In other words, if we authorize SQLServer\LocalGroupA:

* If OURDOMAIN\userA is a member of SQLServer\LocalGroupA, OURDOMAIN\userA login => OK

* If OURDOMAIN\userA is a member of OURDOMAIN\DomainGroupA, and OURDOMAIN\DomainGroupA is a member of SQLServer\LocalGroupA, OURDOMAIN\userA login => FAIL!

Other thoughts we're having that might be somehow relevant, but we can't seem to get around:

1) The domain is mixed Win2000 and Win2003. The SQL Server 2k5 is running on a Win2003 machine that is not a domain controller, but is a domain member.

2) Our AD domain name has a hyphen in it, both in NetBIOS and FQDN (i.e. OUR-DOMAIN and cleveland.our-domain.local)

3) The non-administrative users are accessing the application server via Terminal Services.

None of the above should make a difference (and don't have any problems with SQL Server 2000), but we're really grasping at straws at this point...|||

Can you see if LookupAccountName works for the group name? If you have a small application called name2sid, you could use it to check this. Or you could use something similar to my CLR function from http://blogs.msdn.com/lcris/archive/2005/09/26/474202.aspx.

If this function works ok, then I suggest to open a report on the site indicated in the sticky thread at the top of this forum. You can start the server with the -y18456 parameter, to have it generate a memory dump, and you can attach the dump to the report.

Thanks
Laurentiu

|||I don't have name2sid, but I have the SysInternals "psGetSid" utility, which should do the same thing. Run against OURDOMAIN\TestGroupA, it returns a good SID, so that much is working. If your function or name2sid does something different than this utility, to your knowledge, please let me know and I can try to implement that instead.

I'm not familiar with the -y18456 parameter. I just restarted the SQL Server service with that flag included in the Startup Parameters, but don't see a dump anywhere, or anything especially instructive in the event log. Can you tell me what I should be looking for after restarting with that flag? Once I can find that, I'll open a report on the Connect site. Thanks!|||Please disregard previous request -- I see that it only outputs dumps when that specific error is thrown. Got it, and attaching it to a Connect bug now. Thanks!|||Just for closure on this thread, this issue has been moved to a Connect feedback/bug report. ID is 248615 and can be found here:

https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=248615|||

Hi,

Did you find a fix for this? I think we're having the same problem. I talked to a consultant who thought it was something with our domain since we were running windows 2000 and didnt have the windows DNS running as part of our domain. But everything was working except sql server so I should have known better. So we upgraded our domain controller and spent all kinds of money and it still doesn't work!! Please let me know if you figured out how to fix this!! None of our AD groups are working as logins. Only users and groups on the sql server machine.

Bob Coleman

|||No fix or workaround has been identified yet. Nobody at Microsoft has tagged the Connect bug referenced above, if it has even been reviewed yet. I'm trying to be patient, figuring that people were on vacation over the holidays.

At the moment, we're just maintaining machine-local accounts with the appropriate domain users. Hopefully we'll get some kind of response shortly!|||

We have received your feedback report. When we'll have an update on this issue, we'll update the report.

I am not familiar with the PsSid tool - could you point me to the link from which you downloaded it?

The -y argument can be used with any error number, to make the server produce a dump whenever the error is raised.

Thanks
Laurentiu

|||Certainly! psGetSid was referenced on this page: http://www.microsoft.com/technet/sysinternals/utilities/psgetsid.mspx

It's part of the SysInternals command-line suite that MS acquired earlier this year. Nifty stuff.

Thanks!

Domain group logins failing on SQL 2k5 workgroup

This question is regarding a brand new out-of-the-box SQL Server 2005 Workgroup Edition install. The old SQL Server 2000 server is working properly with regard to the issue we're having:
We are using Windows Authentication, and have created SQL logins for about
40 different groups on our domain. We've given those logins the appropriate
permissions on the databases they're supposed to be able to access. The SQL Server is not a domain controller, but is a member of the domain, and domain logins do work for Windows-login purposes on this box.
The problem is that when users try to connect to the SQL server, they are denied access. An error 18456 is thrown, and logged in the Application event log
stating "Login failed for user OURDOMAIN\theuser" (example values). The
domain user is properly a member of group added as a login to SQL Server, and we've confirmed that there are not conflicting permissions that would deny those
users access via another route. These same groups are working fine on the SQL Server 2000 box.
This is only a problem for domain-based groups. If we create a local group
on the SQL server machine, through Computer Management -> Local Users and
Groups, then make the same domain users a member of THAT group, and finally then follow the same process to add that local group to SQL Server Logins and set
the database privileges, it works!!
Our group memberships change frequently, and are used for a lot more than
just SQL server permissions. So, using local groups and maintaining
membership in both places is not really feasible. Any ideas why a local
machine group containing domain user accounts would work fine, but a domain
group containing the same accounts would not?
Thanks in advance.
Hi,

see if the default database defined for the users / groups ius available and they are granted access to the database. If not they will be denied access to the server and will get the error message posted by you. Did you try to create a single Windows and login with this user ?

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de
|||Single user: Yes. Creating individual logins for domain users works fine. It is only logins for domain groups that are not working.

Default database: The users are connecting via ODBC connections, and the default database is set correctly.

It doesn't seem to be related to any database selection issues at all. Within a single database, if we grant access to the individual user account, or a local machine group that the user is a part of, everything works fine. Grant them access via a domain group, and it denies login. This is not something we've encountered before, and is making me wonder if there is some weird, poorly-documented restriction in the Workgroup Edition...
|||

Please post the error as it is printed in the errorlog file of SQL Server (the ones under MSSQL\...\LOG\ERRORLOG*). Post both the error messages and the error numbers and states - the states are important.

Thanks
Laurentiu

|||(Domain name/IP munged for privacy reasons. Can send via private message if required for some reason.)

With group OURDOMAIN\SecGroupA created on the domain controller, and user 'kswain' made a member of the group. We create a SQL Server login for OURDOMAIN\SecGroupA and get:

2006-12-27 10:45:02.50 Logon Error: 18456, Severity: 14, State: 11.
2006-12-27 10:45:02.50 Logon Login failed for user 'OURDOMAIN\kswain'. [CLIENT: xxx.xxx.xxx.xxx]

With local group TestLocalGroup created on the SQL Server machine, and user 'OURDOMAIN\kswain' added as a member: We create a SQL Server login for SERVERMACHINE\TestLocalGroup using the same process as previously, and it works fine. We don't even have to log the end-user account out of the application... it works as soon as we authorize the local group.

|||

Hi,

Does this error comes when you access from your Application or via Query Analyzer ? Are you able to login via Query Analyzer?

What application you are running !? A web application ? Ensure IIS Permission is also properly set refer below KB

http://support.microsoft.com/kb/316989/

What about connection string in your application ?

Hemantgiri S. Goswami

|||The login failure occurs both from the application and from Query Analyzer using any non-Administrator account.

Our testbed application at the moment is actually just an Access database, using the built-in Windows SQL Server ODBC driver, set up as a Machine DSN. When our main app didn't work, we created the simplest method we could think of to try and connect. We are not using IIS for this at all. We know the DSN itself is set up correctly since it works if the user is explicitly added, or is part of a SQL Server machine-local group.

--
One additional thing we've discovered in the last 24 hours. It still does NOT work if you add a domain group to a local group. So the issue seems to be one of domain group membership resolution. In other words, if we authorize SQLServer\LocalGroupA:

* If OURDOMAIN\userA is a member of SQLServer\LocalGroupA, OURDOMAIN\userA login => OK

* If OURDOMAIN\userA is a member of OURDOMAIN\DomainGroupA, and OURDOMAIN\DomainGroupA is a member of SQLServer\LocalGroupA, OURDOMAIN\userA login => FAIL!

Other thoughts we're having that might be somehow relevant, but we can't seem to get around:

1) The domain is mixed Win2000 and Win2003. The SQL Server 2k5 is running on a Win2003 machine that is not a domain controller, but is a domain member.

2) Our AD domain name has a hyphen in it, both in NetBIOS and FQDN (i.e. OUR-DOMAIN and cleveland.our-domain.local)

3) The non-administrative users are accessing the application server via Terminal Services.

None of the above should make a difference (and don't have any problems with SQL Server 2000), but we're really grasping at straws at this point...
|||

Can you see if LookupAccountName works for the group name? If you have a small application called name2sid, you could use it to check this. Or you could use something similar to my CLR function from http://blogs.msdn.com/lcris/archive/2005/09/26/474202.aspx.

If this function works ok, then I suggest to open a report on the site indicated in the sticky thread at the top of this forum. You can start the server with the -y18456 parameter, to have it generate a memory dump, and you can attach the dump to the report.

Thanks
Laurentiu

|||I don't have name2sid, but I have the SysInternals "psGetSid" utility, which should do the same thing. Run against OURDOMAIN\TestGroupA, it returns a good SID, so that much is working. If your function or name2sid does something different than this utility, to your knowledge, please let me know and I can try to implement that instead.

I'm not familiar with the -y18456 parameter. I just restarted the SQL Server service with that flag included in the Startup Parameters, but don't see a dump anywhere, or anything especially instructive in the event log. Can you tell me what I should be looking for after restarting with that flag? Once I can find that, I'll open a report on the Connect site. Thanks!

|||Please disregard previous request -- I see that it only outputs dumps when that specific error is thrown. Got it, and attaching it to a Connect bug now. Thanks!
|||Just for closure on this thread, this issue has been moved to a Connect feedback/bug report. ID is 248615 and can be found here:

https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=248615
|||

Hi,

Did you find a fix for this? I think we're having the same problem. I talked to a consultant who thought it was something with our domain since we were running windows 2000 and didnt have the windows DNS running as part of our domain. But everything was working except sql server so I should have known better. So we upgraded our domain controller and spent all kinds of money and it still doesn't work!! Please let me know if you figured out how to fix this!! None of our AD groups are working as logins. Only users and groups on the sql server machine.

Bob Coleman

|||No fix or workaround has been identified yet. Nobody at Microsoft has tagged the Connect bug referenced above, if it has even been reviewed yet. I'm trying to be patient, figuring that people were on vacation over the holidays.

At the moment, we're just maintaining machine-local accounts with the appropriate domain users. Hopefully we'll get some kind of response shortly!
|||

We have received your feedback report. When we'll have an update on this issue, we'll update the report.

I am not familiar with the PsSid tool - could you point me to the link from which you downloaded it?

The -y argument can be used with any error number, to make the server produce a dump whenever the error is raised.

Thanks
Laurentiu

|||Certainly! psGetSid was referenced on this page: http://www.microsoft.com/technet/sysinternals/utilities/psgetsid.mspx

It's part of the SysInternals command-line suite that MS acquired earlier this year. Nifty stuff.

Thanks!

Domain change has affected SQL need help

Hey,
One of my clients has migrated from an old NT domain to an AD domain with
Win2K servers. When the migration was performed, SQL 7.0 came across as well
,
but now displays some strange characteristics. NT authentication no longer
works, only SQL authentication.
The MS Search service does not start but I have an article to fix this.
Do I need to do anything else to SQL besides the MS Search service to get
SQL seeing the new domain correctly?
I was never involved in the move of SQL, and now this damn server runs a
mission-critical CRM package on SQL that can in no way be interupted or go
down during the day, and rebuilding is out of the question
Any help would be appreciated.
SQL7 running latest SP. Unfortunately cannot move to SQL 2000.
JoeJoe
SQL Server is a member of domain or stand alone?
Try to delete an old NT/Logins and create a new ones.
"Joe from NZ" <Joe from NZ@.discussions.microsoft.com> wrote in message
news:C79F6DCD-6C16-40B2-9189-1773ECAD335B@.microsoft.com...
> Hey,
> One of my clients has migrated from an old NT domain to an AD domain with
> Win2K servers. When the migration was performed, SQL 7.0 came across as
> well,
> but now displays some strange characteristics. NT authentication no longer
> works, only SQL authentication.
> The MS Search service does not start but I have an article to fix this.
> Do I need to do anything else to SQL besides the MS Search service to get
> SQL seeing the new domain correctly?
> I was never involved in the move of SQL, and now this damn server runs a
> mission-critical CRM package on SQL that can in no way be interupted or go
> down during the day, and rebuilding is out of the question
> Any help would be appreciated.
> SQL7 running latest SP. Unfortunately cannot move to SQL 2000.
> Joe|||Hi Uri,
The server is a member server of an AD domain.
The domain has 2 AD controllers, and 6 member servers.
Joe
"Uri Dimant" wrote:

> Joe
> SQL Server is a member of domain or stand alone?
> Try to delete an old NT/Logins and create a new ones.
>
> "Joe from NZ" <Joe from NZ@.discussions.microsoft.com> wrote in message
> news:C79F6DCD-6C16-40B2-9189-1773ECAD335B@.microsoft.com...
>
>

Domain change has affected SQL need help

Hey,
One of my clients has migrated from an old NT domain to an AD domain with
Win2K servers. When the migration was performed, SQL 7.0 came across as well,
but now displays some strange characteristics. NT authentication no longer
works, only SQL authentication.
The MS Search service does not start but I have an article to fix this.
Do I need to do anything else to SQL besides the MS Search service to get
SQL seeing the new domain correctly?
I was never involved in the move of SQL, and now this damn server runs a
mission-critical CRM package on SQL that can in no way be interupted or go
down during the day, and rebuilding is out of the question
Any help would be appreciated.
SQL7 running latest SP. Unfortunately cannot move to SQL 2000.
Joe
Joe
SQL Server is a member of domain or stand alone?
Try to delete an old NT/Logins and create a new ones.
"Joe from NZ" <Joe from NZ@.discussions.microsoft.com> wrote in message
news:C79F6DCD-6C16-40B2-9189-1773ECAD335B@.microsoft.com...
> Hey,
> One of my clients has migrated from an old NT domain to an AD domain with
> Win2K servers. When the migration was performed, SQL 7.0 came across as
> well,
> but now displays some strange characteristics. NT authentication no longer
> works, only SQL authentication.
> The MS Search service does not start but I have an article to fix this.
> Do I need to do anything else to SQL besides the MS Search service to get
> SQL seeing the new domain correctly?
> I was never involved in the move of SQL, and now this damn server runs a
> mission-critical CRM package on SQL that can in no way be interupted or go
> down during the day, and rebuilding is out of the question
> Any help would be appreciated.
> SQL7 running latest SP. Unfortunately cannot move to SQL 2000.
> Joe
|||Hi Uri,
The server is a member server of an AD domain.
The domain has 2 AD controllers, and 6 member servers.
Joe
"Uri Dimant" wrote:

> Joe
> SQL Server is a member of domain or stand alone?
> Try to delete an old NT/Logins and create a new ones.
>
> "Joe from NZ" <Joe from NZ@.discussions.microsoft.com> wrote in message
> news:C79F6DCD-6C16-40B2-9189-1773ECAD335B@.microsoft.com...
>
>

Domain change has affected SQL need help

Hey,
One of my clients has migrated from an old NT domain to an AD domain with
Win2K servers. When the migration was performed, SQL 7.0 came across as well,
but now displays some strange characteristics. NT authentication no longer
works, only SQL authentication.
The MS Search service does not start but I have an article to fix this.
Do I need to do anything else to SQL besides the MS Search service to get
SQL seeing the new domain correctly?
I was never involved in the move of SQL, and now this damn server runs a
mission-critical CRM package on SQL that can in no way be interupted or go
down during the day, and rebuilding is out of the question :(
Any help would be appreciated.
SQL7 running latest SP. Unfortunately cannot move to SQL 2000. :(
JoeJoe
SQL Server is a member of domain or stand alone?
Try to delete an old NT/Logins and create a new ones.
"Joe from NZ" <Joe from NZ@.discussions.microsoft.com> wrote in message
news:C79F6DCD-6C16-40B2-9189-1773ECAD335B@.microsoft.com...
> Hey,
> One of my clients has migrated from an old NT domain to an AD domain with
> Win2K servers. When the migration was performed, SQL 7.0 came across as
> well,
> but now displays some strange characteristics. NT authentication no longer
> works, only SQL authentication.
> The MS Search service does not start but I have an article to fix this.
> Do I need to do anything else to SQL besides the MS Search service to get
> SQL seeing the new domain correctly?
> I was never involved in the move of SQL, and now this damn server runs a
> mission-critical CRM package on SQL that can in no way be interupted or go
> down during the day, and rebuilding is out of the question :(
> Any help would be appreciated.
> SQL7 running latest SP. Unfortunately cannot move to SQL 2000. :(
> Joe|||Hi Uri,
The server is a member server of an AD domain.
The domain has 2 AD controllers, and 6 member servers.
Joe
"Uri Dimant" wrote:
> Joe
> SQL Server is a member of domain or stand alone?
> Try to delete an old NT/Logins and create a new ones.
>
> "Joe from NZ" <Joe from NZ@.discussions.microsoft.com> wrote in message
> news:C79F6DCD-6C16-40B2-9189-1773ECAD335B@.microsoft.com...
> > Hey,
> >
> > One of my clients has migrated from an old NT domain to an AD domain with
> > Win2K servers. When the migration was performed, SQL 7.0 came across as
> > well,
> > but now displays some strange characteristics. NT authentication no longer
> > works, only SQL authentication.
> > The MS Search service does not start but I have an article to fix this.
> >
> > Do I need to do anything else to SQL besides the MS Search service to get
> > SQL seeing the new domain correctly?
> >
> > I was never involved in the move of SQL, and now this damn server runs a
> > mission-critical CRM package on SQL that can in no way be interupted or go
> > down during the day, and rebuilding is out of the question :(
> >
> > Any help would be appreciated.
> > SQL7 running latest SP. Unfortunately cannot move to SQL 2000. :(
> >
> > Joe
>
>

DOH! Uninstall of 2005 gone horribly wrong

I am an old hand at RDBMS but have been using SQL Server for only 1 year. I have a local install of 2005 Developer Edition, and also access a number of 2000 and 2005 instances on remote and network servers. OK, so on 3/16 (after installing the 3/15 Windows Security Updates), I began getting this error when invoking any 2005 DB under Object Explorer in Management Studio "SQLWB - SQL Server Management Studio has encountered a problem and needs to close. We are sorry for the inconvenience." Very helpful. So I ran a debug and got some unhandled exception errors:

'SqlWb.exe': Loaded 'C:\WINDOWS\system32\wbem\wbemsvc.dll', No symbols loaded.
'SqlWb.exe': Loaded 'C:\WINDOWS\system32\wbem\fastprox.dll', No symbols loaded.
'SqlWb.exe': Loaded 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\diasymreader.dll', No symbols loaded.
'SqlWb.exe': Loaded 'C:\WINDOWS\system32\apphelp.dll', No symbols loaded.
The thread 'Win32 Thread' (0x21c) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0xa98) has exited with code 0 (0x0).
Unhandled exception at 0x79ea69f3 in SqlWb.exe: 0xC0000006: In page error.
First-chance exception at 0x79ea69f3 in SqlWb.exe: 0xC0000005: Access violation reading location 0x088b200c.
Unhandled exception at 0x79ea69f3 in SqlWb.exe: 0xC0000005: Access violation reading location 0x088b200c.
First-chance exception at 0x79ea69f3 in SqlWb.exe: 0xC0000005: Access violation reading location 0x088b200c.

After some poking around, my DBA told me that we had upgraded the servers for our team to SP1, and I should install that, because the file being read did not 'match up' with the commands. But when I did so I got the warning:

- Edition Change Check (Warning)

Messages

Edition Change Check

To change an existing instance of Microsoft SQL Server 2005 to a different edition of SQL Server 2005, you must run SQL Server 2005 Setup from the command prompt and include the SKUUPGRADE=1 parameter.

I researched this information, but it didn't really apply to my situation. So I selected 'CONTINUE' and everything went downhill from there. The install downloaded the SP1 setup support files (which by the way "cannot be removed") and then aborted. I poked around some more and decided it would be easiest to Uninstall and Reinstall the Dev Edition from the DVD and then apply the SP. The uninstall went fine until it got to the tools (which apparently were my real problem to start with). When I attempt to uninstall the tools, I get the following message:

"Error reading from file C:\Windows\assembly\GAC_MSIL\Microsoft.SqlServer.SqlEnum\9.0.242.0__89845dcd8080cc91\Microsoft.SqlServer.SqlEnum.dll

Verify that this file exists and that you can access it"

This message is presented with Retry and Cancel options. The file does NOT exist, so Retry is not useful and cancel rolls back the entire uninstall.

Error signature:

EventType : sql90setup P1 : installfinalize P2 : 0x643 P3 : unknown
P4 : 0x519 P5 : unknown P6 : unknown
P7 : sqlrun_tools.msi@.9.00.1399.06

In this part SP1/half uninstalled 2005 environment I am stuck like chuck. I have searched for this dll online and on other folders of my hard drive to no avail. I have also dug through these forums until my eyes are crossed.

Can anyone help?!?

One more search location turned up the answer here: http://support.microsoft.com/default.aspx/kb/909953

Turns out the tools are considered components. You can remove services and instances from the REMOVE dialog, but you have to CHANGE the client components (under workstation components) and de-select Management Tools.

I cannot believe how long it took me to find this; I finally found it today in the setup help information on the install DVD while preparing for the install. I'll leave this here for others who check the boards before the knowledge base.

THANKS to anyone who put thought into this today.

|||

Thanks for following up your own post. It prevents others from wasting their time trying to help you after you have solved the problem, and it helps others when you share your solution.