Major SQL Server 2k5 x64 configuration problem

Dear All,
I've just installed two brand new SQL Server servers with Windows 2003
Server 2003 R2 + SP2 and SQL Server 2005 Standard Edition + SP2.
I now need to configure the network protocols for SQL Server on these
machines, but on both machines the SQL Server instances are not showing up in
the "SQL Server 2005 Configuration manager"
On two other x64 SQL Server 2005 servers which we installed last year I see
a total of 5 icons in the "SQL Server 2005 Configuration manager":
- SQL Server 2005 Services
- SQL Server 2005 Network configuration (32-bit)
- SQL Server 2005 Native Client Configuration (32 Bit)
- SQL Server 2005 Network configuration
- SQL Server 2005 Native Client Configuration
but on the two new servers only the first 3 groups are showing up.
Normaly the x64 Instances are listed in the group as "- SQL Server 2005
Network configuration", but this group is not showing up.
On both servers I only have configured a default (non-named) instance.
Does anybody have a clue what can be wrong or have a hint as where to start
searching for a solution?
Because we posted this question earlier and have not received a single
response I've resorted to crossposting to the following groups:
microsoft.public.sqlserver.server
microsoft.public.sqlserver.tools
microsoft.public.sqlserver.security
microsoft.public.sqlserver.setup
Kind regards,
Tom and Nick, Reeleezee
Solved: through security access failure auditing we saw that user "NETWORK
SERVICE" was getting access denieds for C:\Program Files\Microsoft SQL
Server\90\Shared\sqlmgmprovider.dll.
This was because we ourselves routinely implemented our security lock-down
policy of denying Read/Execute access to "C:\Program Files" and "C:\Program
Files (x86)" to the local USERS group which NETWORK SERVICE belongs to
through being an authenticated user.
We hadn't suspected such a security issue when running the tool as
administrator but apparently the Configuration Tool asks WMI to enumerate the
SQL Server instances and WMI does this under the NETWORK SERVICE account.
(not so for the 32-bit nodes?)
We have had no other issue whatsoever from applying our lock-down policy. I
hope this gets into the MS knowledge base.
Nick
"Nick" wrote:

> Dear All,
> I've just installed two brand new SQL Server servers with Windows 2003
> Server 2003 R2 + SP2 and SQL Server 2005 Standard Edition + SP2.
> I now need to configure the network protocols for SQL Server on these
> machines, but on both machines the SQL Server instances are not showing up in
> the "SQL Server 2005 Configuration manager"
> On two other x64 SQL Server 2005 servers which we installed last year I see
> a total of 5 icons in the "SQL Server 2005 Configuration manager":
> - SQL Server 2005 Services
> - SQL Server 2005 Network configuration (32-bit)
> - SQL Server 2005 Native Client Configuration (32 Bit)
> - SQL Server 2005 Network configuration
> - SQL Server 2005 Native Client Configuration
> but on the two new servers only the first 3 groups are showing up.
> Normaly the x64 Instances are listed in the group as "- SQL Server 2005
> Network configuration", but this group is not showing up.
> On both servers I only have configured a default (non-named) instance.
> Does anybody have a clue what can be wrong or have a hint as where to start
> searching for a solution?
> Because we posted this question earlier and have not received a single
> response I've resorted to crossposting to the following groups:
> microsoft.public.sqlserver.server
> microsoft.public.sqlserver.tools
> microsoft.public.sqlserver.security
> microsoft.public.sqlserver.setup
>
> Kind regards,
> Tom and Nick, Reeleezee
|||File it as a bug on Connect (Connect.microsoft.com) and it will make it to
the dev team. Whether this makes it all the way to KB article is an
entirely different matter.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Nick" <SaintNick@.nospam.nospam> wrote in message
news:0EC7C9F4-EB90-466A-ABC9-BB72E74FECA9@.microsoft.com...[vbcol=seagreen]
> Solved: through security access failure auditing we saw that user "NETWORK
> SERVICE" was getting access denieds for C:\Program Files\Microsoft SQL
> Server\90\Shared\sqlmgmprovider.dll.
> This was because we ourselves routinely implemented our security lock-down
> policy of denying Read/Execute access to "C:\Program Files" and
> "C:\Program
> Files (x86)" to the local USERS group which NETWORK SERVICE belongs to
> through being an authenticated user.
> We hadn't suspected such a security issue when running the tool as
> administrator but apparently the Configuration Tool asks WMI to enumerate
> the
> SQL Server instances and WMI does this under the NETWORK SERVICE account.
> (not so for the 32-bit nodes?)
> We have had no other issue whatsoever from applying our lock-down policy.
> I
> hope this gets into the MS knowledge base.
> Nick
> "Nick" wrote:
|||Nick,
Another set of problems may arise if you also locked down WINDOWS\SysWOW64
(the 32-bit stuff) or WINDOWS\System32 (the 64-bit stuff). For example, this
can prevent the appropriate version of cscript from running, should you have
a SQL Agent job with a cscript step. (And the error message will not be
obvious.)
RLF
"Nick" <SaintNick@.nospam.nospam> wrote in message
news:0EC7C9F4-EB90-466A-ABC9-BB72E74FECA9@.microsoft.com...[vbcol=seagreen]
> Solved: through security access failure auditing we saw that user "NETWORK
> SERVICE" was getting access denieds for C:\Program Files\Microsoft SQL
> Server\90\Shared\sqlmgmprovider.dll.
> This was because we ourselves routinely implemented our security lock-down
> policy of denying Read/Execute access to "C:\Program Files" and
> "C:\Program
> Files (x86)" to the local USERS group which NETWORK SERVICE belongs to
> through being an authenticated user.
> We hadn't suspected such a security issue when running the tool as
> administrator but apparently the Configuration Tool asks WMI to enumerate
> the
> SQL Server instances and WMI does this under the NETWORK SERVICE account.
> (not so for the 32-bit nodes?)
> We have had no other issue whatsoever from applying our lock-down policy.
> I
> hope this gets into the MS knowledge base.
> Nick
> "Nick" wrote: