Computer \\computername cannot be managed because it is not running Windows NT

[borntom]

After disabling 'NetBIOS over TCP/IP' via DHCP some of our computers
can not be managed remotely. So far, it seems only to affect computer
running Windows XP SP2. The strange thing is that this happens not all
of the time, sometimes after a reboot everything as OK and vice versa.

When attempting to connect to one of the computers in question using
computer management (from any server or workstation) one receives this
message:
Computer \\computername cannot be managed because it is not running
Windows NT. Would you like to manage it anyway?

Some other remote administration tools do not work at all.

After using Wireshark it turned out the computer does identify itself
via Server Message Block (SMB) NetServerGetInfo as
'Server Type: 0x0000001' and not as 'Server Type: 0x0001003'.

That means that the computer identifies itself incorrectly only as
'Workstation' and not as 'Workstation', 'Server' and 'NT Workstation'.

The identification as 'Server' and 'NT Workstation' should be carried
out if 'File and Printer Sharing for Microsoft Networks' is installed
and activated on the network interface card, according to
http://support.microsoft.com/kb/262597/en-us and our observations.
Sadly reinstalling 'File and Printer Sharing for Microsoft Networks'
does only fixes the problem till the next reboot. Reinstalling the
'Client Microsoft for Networks' doesn't fix the problem longer than the
next reboot. Re-enabling 'NetBIOS over TCP/IP' via DHCP does fix the
problem, but want to have 'NetBIOS over TCP/IP' disabled.

The were some posts mentioning the same problem:
http://groups.google.com/groups?hl=...+it+is+not+running+Windows+NT"&Submit3=Search

We think it could be an error in Windows XP SP2.

Is there anyone with an idea how this problem can be fixed? Any help
would be appreciated.

 

[Lanwench [MVP - Exchange]]

My reply is at the bottom of your message.

In

After disabling 'NetBIOS over TCP/IP' via DHCP some of our computers
can not be managed remotely. So far, it seems only to affect computer
running Windows XP SP2. The strange thing is that this happens not all
of the time, sometimes after a reboot everything as OK and vice versa.

When attempting to connect to one of the computers in question using
computer management (from any server or workstation) one receives this
message:
Computer \\computername cannot be managed because it is not running
Windows NT. Would you like to manage it anyway?

Some other remote administration tools do not work at all.

After using Wireshark it turned out the computer does identify itself
via Server Message Block (SMB) NetServerGetInfo as
'Server Type: 0x0000001' and not as 'Server Type: 0x0001003'.

That means that the computer identifies itself incorrectly only as
'Workstation' and not as 'Workstation', 'Server' and 'NT Workstation'.

The identification as 'Server' and 'NT Workstation' should be carried
out if 'File and Printer Sharing for Microsoft Networks' is installed
and activated on the network interface card, according to
http://support.microsoft.com/kb/262597/en-us and our observations.
Sadly reinstalling 'File and Printer Sharing for Microsoft Networks'
does only fixes the problem till the next reboot. Reinstalling the
'Client Microsoft for Networks' doesn't fix the problem longer than
the next reboot. Re-enabling 'NetBIOS over TCP/IP' via DHCP does fix
the problem, but want to have 'NetBIOS over TCP/IP' disabled.

The were some posts mentioning the same problem:
http://groups.google.com/groups?hl=...+it+is+not+running+Windows+NT"&Submit3=Search

We think it could be an error in Windows XP SP2.

Is there anyone with an idea how this problem can be fixed? Any help
would be appreciated.

I have no idea, but a) I always enable NetBIOS over TCP/IP as it just seems
to work better and b) if you run WINS there's little downside to it. What's
the reason you disabled it in the first place, if you don't mind my asking?
A lot of stuff still relies on it, sad to say.

 

[Steven L Umbach]

You could try using the computers IP address as a workaround. Otherwise you
will probably have to keep using netbios over tcp/ip. Is there a specific
reason why you feel the need to disable netbios over tcp/ip??

Steve

 

[borntom]

Using the IP does not help, the computer still identifies itself as
'Server Type: 0x0000001' and not as 'Server Type: 0x0001003'. On the
computers, which still identify themselves correct, we had no problems
without 'NetBIOS over TCP/IP'.

In addition since 'My Network Places' is broadcast based and
therefore every device can claim to be everything via broadcast
disabling 'NetBIOS over TCP/IP' and therefore loosing 'My Network
Places' is one step to more security.

 

[Lanwench [MVP - Exchange]]

In

Using the IP does not help, the computer still identifies itself as
'Server Type: 0x0000001' and not as 'Server Type: 0x0001003'. On the
computers, which still identify themselves correct, we had no problems
without 'NetBIOS over TCP/IP'.

In addition since 'My Network Places' is broadcast based and
therefore every device can claim to be everything via broadcast

Use WINS.

disabling 'NetBIOS over TCP/IP' and therefore loosing 'My Network
Places' is one step to more security.

? I have never heard of anyone disabling this for security reasons.

 

[Steven L Umbach]

That is weird as usually using the IP address works as it removes the need
to use name resolution. I can't say much more as to why it does not work on
SP2 as I have never had a need to disable NBT. You may also want to post in
the networking newsgroup to see if anyone there has seen the same behavior.
In my opinion disabling NBT does little to nothing to improve network
security. Using ipsec, if needed, would do a whole lot more to increase
network security including requring that computers authenticate with each
other before access is allowed on defined ports/protocols/IP and the ability
to encrypt and guarantee authenticity of network traffic.

Steve

 

[borntom]

It's not a matter of name resolution. Using WINS or DNS or the IP
itself, the result is always the same, the computer itself wrongly
identify itself, as soon as you disable NetBIOS. Well on some
computers, not all and not all of the time. Using regmon or filemon
from sysinternals I could not find a reason. I also could not find a
registry key which has something to do as which the computer identifies
itself.

So the conclusion is: We were using NetBIOS including WINS, we wanted
to use only DNS, but turning off NetBIOS did produce non predictable
results on some Windows XP computers, so we turned it back on.

Thanks to all for their feedback.

Thomas

 

[Lanwench [MVP - Exchange]]

In

It's not a matter of name resolution. Using WINS or DNS or the IP
itself, the result is always the same, the computer itself wrongly
identify itself, as soon as you disable NetBIOS.

What exactly does "wrongly identifies itself" mean?

Well on some
computers, not all and not all of the time. Using regmon or filemon
from sysinternals I could not find a reason. I also could not find a
registry key which has something to do as which the computer
identifies itself.

So the conclusion is: We were using NetBIOS including WINS, we wanted
to use only DNS, but turning off NetBIOS did produce non predictable
results on some Windows XP computers, so we turned it back on.

You might as well, honestly. It's still used and needed more than you think.
And frankly, I really like being able to browse.

 

[borntom]

To distinguish between the two computers, I call them 'computer/server'
and 'computer/client'. The identification happens when a TCP session
betwenn the two computer has still been started.

It means that the computer/server in question does identify itself to
the other computer/client which 'wants' to manage it via Server Message
Block (SMB) and queries the computer/server capabilities via
SMB/NetServerGetInfo as:
'Server Type: 0x0000001' which means it (computer/server) is a
'Workstation'

but it should identify itself as 'Server Type: 0x0001003' which menas
it is a 'Workstation', 'Server' and 'NT Workstation'.

This wrong identification does only happen sometimes on some computers.
I can send you a WireShark trace if you want to.


OK, being not able to browse is a disadvantage one have to bear if
'NetBIOS over TCP/IP' is disabled.

Best regards
Thomas

 

[Lanwench [MVP - Exchange]]

In

To distinguish between the two computers, I call them
'computer/server' and 'computer/client'. The identification happens
when a TCP session betwenn the two computer has still been started.

It means that the computer/server in question does identify itself to
the other computer/client which 'wants' to manage it via Server
Message Block (SMB) and queries the computer/server capabilities via
SMB/NetServerGetInfo as:
'Server Type: 0x0000001' which means it (computer/server) is a
'Workstation'

but it should identify itself as 'Server Type: 0x0001003' which menas
it is a 'Workstation', 'Server' and 'NT Workstation'.

This wrong identification does only happen sometimes on some
computers. I can send you a WireShark trace if you want to.

No, that's OK, thanks. I guess I'm not really sure what the issue is here
anyway - maybe I'm missing something. A server has a workstation service. A
workstation has a server service.

OK, being not able to browse is a disadvantage one have to bear if
'NetBIOS over TCP/IP' is disabled.

Yep, and there are other things (legacy apps, etc) that will not work if
it's disabled.