Komodo Labs Forums

NEWT Professional => NEWT Pro Network Inventory - Support => Topic started by: Dave on November 01, 2004, 05:25:35 PM

Title: Permissions problems (fixed as of v2.5)
Post by: Dave on November 01, 2004, 05:25:35 PM
I have a number of remote servers that I need to run NEWT against.  They are not on the domain, and may not all be in the same workgroup.  I understand from other posts that a local account with identical username and password on each box is required to allow connection.  I have such an account available and it is not working.  This account is Administrator on all boxes involved, but even installing NEWT on one of these boxes, and running it from there will not allow me to see anything more that the server name.  This goes for all boxes, including the one that I run it from.  

I suspect that the Windows Management Instrumentation service must be running for NEWT to deliver anything.  I also see that this service is dependent upon the RPC service being running.  I’ve spot checked and I can not find an instance of either of these servers being down.  I keep running into the feeling that some boxes, (local as well as remote), have had certain default rights which are required by NEWT removed from their administrators group.  Can you tell me more about what rights must be held to a box for NEWT to work?
Title: Permissions problems (fixed as of v2.5)
Post by: Komodo Support on November 01, 2004, 07:48:43 PM
Hello Dave.  NEWT does require WMI, but also requires remote registry access.  For machines on any workgroup, NEWT 1.0 requires you have default access to the remote machine.  In other words, the remote user must be logged in as the same username/password you're logged in with.  If you can open the remote registry and browse to the following registry path, NEWT should be able to scan that machine:


If you are asked for a username/password and you're able to get access after typing it in, please let me know.  In that case I would suggest us sending you the latest 2.0 version.  It has the ability to use custom usernames/passwords, for each machine if needed as well as many other improvements.  We could email you with the info to the address you signed up with on the forums if you'd like.

You mention you've tried installing NEWT on one of the problem machines and running it from there.  Are you saying you can't scan one of these machines locally when NEWT is installed on that very machine?  If so there could be a few different reasons, but one could be that the logged in user for that machine doesn't have administrator rights to his or her own workstation.  I also assume these are all NT-based machines? (NT4, W2K, XP)
Title: Permissions problems (fixed as of v2.5)
Post by: Dave on November 02, 2004, 01:18:19 PM
We own a mix of servers that happen to coexist in the IP range I scan with NEWT, but I’m only looking for data from Windows machines.  We own a mix of NT, W2K, and 2003.  The specific server I’ve been working on to “get one working” is NT Server 4.0.

I created a local user on the NEWT installed machine on my domain with the same username and password as the one on the machines in the workgroups.  I had successfully tried remote registry access looking at the target workgroup machine before and the key you specify is indeed also available through a remote registry connection.  Unfortunately NEWT picked up that it was NT server 4.0 and a Server, on the PRIMARY tab, but did not give me anything more.  The other tabs are blank in regards to that server.  When I had installed NEWT on that workgroup server as a test I got the same results that I am getting from the domain server I have it on now.  In all instances the local user is in the administrator’s group, and the password is the same.  I’d imagine that if it didn’t have permission to read the registry locally, I wouldn’t be able to use that account name remotely either.
Title: Permissions problems (fixed as of v2.5)
Post by: Komodo Support on November 02, 2004, 03:46:43 PM
This sounds like a machine-specific problem.  We will contact you privately in email to provide further assistance.