NOTICE: Significant community changes coming soon
The header menu and the home page on our community will be changing soon. Get more information HERE.
Highlighted
Honored Contributor.
Honored Contributor.
1140 views

Problems discovering Windows servers with nt / 2000 operating system

I have problems to discover windows servers with old OS (NT / 2000),
I have managed to secure firewall permissions for the required ports; However, something else must be missing because it is not possible to discover them.
Does anyone have any idea what user permissions should be requested? or what settings should be made? for example in the regedit?

I appreciate your answers.

0 Likes
18 Replies
Highlighted
Trusted Contributor.
Trusted Contributor.

Hi,

 

Aslong netbios is working you can discover windows NT devices isomg NTCMD protocol in UCMDB.

It uses the following ports: UDP Ports 137 (netbios_ns), 138 (netbios_dg) and TCP 139 (netbios_ss) for SMB access.

We have very little windows NT devices left so we are migrating everyring to powerCMD protocol in the discoverys (using the NTCMD discovery jobs but access the servers using powershell instead of NTCMD).

0 Likes
Highlighted
Honored Contributor.
Honored Contributor.

Is there any additional configuration or permission that should be requested?
They tell me that they have already enabled the NTCMD ports, however I can not find them.
How to test the connection to UDP ports from the probe?

Error:windows.jpeg

Thanks,

0 Likes
Highlighted
Highlighted
Honored Contributor.
Honored Contributor.

Hi Lee - 

unfortunately this configuration had already been made.
Verify it yourself:

  regedit.PNG

Note: I want to clarify that the servers were discovered incompletely since they are virtualized (Topology VCenter), however the server is not discovered by operating system, I can not see cpu, fylesystem, installedSoftware and others.

Is it necessary to make some adjustment in the regedit of the servers to discover?

Thanks,

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

This might sound studpid but why not discover NT/2000 over telnet? I know, it's a very unsecure protocol but having in mind the age of those operating systems I don't think it will be such abig problem. Just by still having them is a security problem.

There's also the option of SNMP.

For Windows 2000 we can use WMI to some degree. The WMI implementation in Windows 2000 is rudimentary compared to the latest Windows servers but it can bring data.

 

Kind regards,
Bogdan Mureșan

EMEA Technical Success
0 Likes
Highlighted
Honored Contributor.
Honored Contributor.

I can not discover those windows servers by protocols other than SSH Protocol, NTCMD Protocol, Universal Discovery Protocol, PowerCmd Protocol since these are the ones required by the job Inventory Discovery by Scanner to discover the installedSoftware (Windows Server) and send it to Asset Manager and count the licenses.

However at this time it would be interesting to discover the basic topology by telnet, and for what I need? User permission (local or domain), what commands? and the connection port must be 23?

Thanks,

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Telnet will run OOTB on port 23. You can use a local account, never tried with a domain account to be honest.

You can also use SSH but that will imply to deploy a SSH server on those old Windows machines. Yes, we do Support disocvery of Windows machines over SSH.

Kind regards,
Bogdan Mureșan

EMEA Technical Success
0 Likes
Highlighted
Honored Contributor.
Honored Contributor.

I will try to discover by telnet, I will request the permissions to port 23 since no server answers me and I will do the test with a local user (hopefully administrator).
Interesting to know if there is support for Windows operating systems discovered with SSH. I'll have to investigate later how to do it.

Regards.

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

As I said before, telent should be an approach for those old NT servers but I would ues it as a temporary solution. It's telent, we shouldn't even support it anymore, it's that old and unsecure 🙂

For the discovery of Windows machines using SSH we have some options and we have some customers who use it instead of NTCMD or telnet or SNMP.

It's very useful for surface discovery and it's much safer than NTCMD. Much more secure than NTCMD. The discovery flow is the same, only the connection and transport protocol is different. The result vector will be the same between SSH discovery and NTCMD discovery.
Actually we have some specific discovery flows over shell which work also via SSH like MS Clusters by shell. It was designed to be used via NTCMD but it works via SSH also. That's one example which I remembered.

Kind regards,
Bogdan Mureșan

EMEA Technical Success
0 Likes
Highlighted
Honored Contributor.
Honored Contributor.

Why reccomend use local user is?

Are those error messages known from the image?
Or should I ask an administrator windows?

*The other option is to try to discover with the UDA agent, but I would like to filter only so that the agent is installed on these servers (approximately 40) and not above all.
Do you think it is a viable option?

Thanks Again,

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

When you are using a domain user the connection may inherit domain credentials. Sometimes this is good and sometimes not, depeding on your particular network.
OOTB we have local user so this would be a good starting point.
If you deploy UDA on those 40 machines then you can set UDA as the first connection, there is a parameter for that on Host connection jobs and similar.

Kind regards,
Bogdan Mureșan

EMEA Technical Success
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.