Komodo Labs Forums
NEWT Professional => NEWT Pro Network Inventory - Support => Topic started by: AutoCan on June 27, 2010, 03:35:31 PM
-
Getting this error on my Windows 7 Machines....
All it says is Low-Level Cannot install Error:6
-
Hello there. This isn\'t a common error, but we\'ve seen it recently and believe it\'s related to a default security policy for PCs on Windows 2008 Server (latest service pack). We will contact you directly about resolving this issue.
-
Hi,
I have just purchased this software to audit our 70 odd machines.
I am too getting the
Low-Level : Could not install service on [SYSTEMNAME]
It just so happens to be that the machines that are having the issues are Vista and Windows 7.
Is there a work around? I would like to know becuase within the next 2 months all of our machines are going to be upgraded to Windows 7. I would like to know if this software is going to be any use to me now that i have just purchased it.
-
Hello there. We are currently working with users to find out why this is happening. We believe it\'s a security setting remote service installation. We will contact you directly by email since it may be more efficient.
-
Hello,
I am having the same problem as the others. The domain server is functional 2003 level, 2008R2 OS. The XP clients are working okay but the win7 clients are not. Have you discovered anything useful yet?
-
I figured out something that may help. I am a domain admin in a different domain than the computer I am trying to scan. Although I enter domain credentials in the credential manager for the domain I am trying to scan when I view the log of the win7 client I find the service for newt is trying to install using the credentials of the current logged on user, which I am, as a domain admin but in the wrong domain. So it seems the newt service should use the credentials I specify to install the service on the client but it does not. I verified by the security log. I can right click and choose to run newt as and enter the domain admin credentials from the same domain as the client and everything works.
So, why doesn\'t the service get installed using the credentials in the credential manager?
-
Apologies for the delay, and thank you for that. We haven\'t found a solution for this issue yet, but it sounds like your investigation has uncovered something useful.
NEWT should be using the same credentials, as the Windows Service Manager APIs we use to create & start the service do not seem to have credential options. It uses whatever security context we\'ve used to connect. And because NEWT was able to get to the ADMIN$ share, it assumes we have normal administrator rights. That said, there might be something we\'re overlooking.
I wanted to make sure of a couple things first:
1. Are you using v2.5.170?
2. If so, can you right-click and paste the exact error you\'re getting so we can track it down in code?
3. In NEWT\'s Credential Manager, are you using \"DOMAIN\\Username\" as the user name instead of simply the user name?
Thanks again for help us with this!
-
Low-Level could not install service on 10.12.2.3, error 5 while opening SCManager: (Access is denied.) trying again...
above is in the newt console from the latest version 2.5 build 170.
below is in the security log of the client, I have overwritten some info for privacy purposes. Now once the service is installed the product works fine. If removed and rescanned the same problem. I would have to capture more information to tell which credentials are used for a scan once the service is installed but I suspect the ones from the credential manager are being used. Yes I always use domain\\username in the credential manager or username@domain.
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 10/13/2010 4:10:02 PM
Event ID: 4656
Task Category: Other Object Access Events
Level: Information
Keywords: Audit Failure
User: N/A
Computer: FQDN of machine being scanned
Description:
A handle to an object was requested.
Subject:
Security ID: domain\\username
Account Name: username
Account Domain: domain
Logon ID: 0x53a7ef
Object:
Object Server: SC Manager
Object Type: SC_MANAGER OBJECT
Object Name: ServicesActive
Handle ID: 0x0
Process Information:
Process ID: 0x270
Process Name: C:\\Windows\\System32\\services.exe
Access Request Information:
Transaction ID: {00000000-0000-0000-0000-000000000000}
Accesses: DELETE
READ_CONTROL
WRITE_DAC
WRITE_OWNER
Connect to service controller
Create a new service
Enumerate services
Lock service database for exclusive access
Query service database lock state
Set last-known-good state of service database
Access Reasons: -
Access Mask: 0xf003f
Privileges Used for Access Check: -
Restricted SID Count: 0
Event Xml:
<Event xmlns=\"http://schemas.microsoft.com/win/2004/08/events/event\">
<System>
<Provider Name=\"Microsoft-Windows-Security-Auditing\" Guid=\"{54849625-5478-4994-A5BA-3E3B0328C30D}\" />
<EventID>4656</EventID>
<Version>1</Version>
<Level>0</Level>
<Task>12804</Task>
<Opcode>0</Opcode>
<Keywords>0x8010000000000000</Keywords>
<TimeCreated SystemTime=\"2010-10-13T20:10:02.865862100Z\" />
<EventRecordID>867495</EventRecordID>
<Correlation />
<Execution ProcessID=\"632\" ThreadID=\"640\" />
<Channel>Security</Channel>
<Computer>MKmettT1500.pa.local</Computer>
<Security />
</System>
<EventData>
<Data Name=\"SubjectUserSid\">S-1-5-21-2034437564-991321795-1401906445-1113</Data>
<Data Name=\"SubjectUserName\">username</Data>
<Data Name=\"SubjectDomainName\">domain</Data>
<Data Name=\"SubjectLogonId\">0x53a7ef</Data>
<Data Name=\"ObjectServer\">SC Manager</Data>
<Data Name=\"ObjectType\">SC_MANAGER OBJECT</Data>
<Data Name=\"ObjectName\">ServicesActive</Data>
<Data Name=\"HandleId\">0x0</Data>
<Data Name=\"TransactionId\">{00000000-0000-0000-0000-000000000000}</Data>
<Data Name=\"AccessList\">%%1537
%%1538
%%1539
%%1540
%%7168
%%7169
%%7170
%%7171
%%7172
%%7173
</Data>
<Data Name=\"AccessReason\">-</Data>
<Data Name=\"AccessMask\">0xf003f</Data>
<Data Name=\"PrivilegeList\">-</Data>
<Data Name=\"RestrictedSidCount\">0</Data>
<Data Name=\"ProcessId\">0x270</Data>
<Data Name=\"ProcessName\">C:\\Windows\\System32\\services.exe</Data>
</EventData>
</Event>
-
Thank you, that helps. So you\'re saying you\'re able to scan XP PCs on that remote domain just fine, but just not Win7 PCs?
Also, are you scanning *from* an XP PC, or from a Win7 box?
-
I am scanning from a win7 machine and from another domain.
Scanning an xp machine works fine.
Scanning a win7 machine has the error. Once service is installed further scanning is fine.
both clients are in the same domain, one different than mine.
I can use \"run as\" a domain admin from the client domain and the install of the service works. After that I can scan without having to \"run as\".
UAC on client is off. Firewall is off.
-
Ok, we\'re going to start by email you a simple BAT file that writes to a log. You\'ll need to edit it to use your credentials. This is the first step in determining what\'s going on. It may take more testing, but we\'ll get this figured out with your help.
-
The BAT file has been emailed as a Zip file.
-
I am having the same issue when trying to scan Windows 7 Machines. I am running Windows 7 as well. I am able to scan xp machines just fine but get this error when trying to scan windows 7 machines.
Low-Level: could not install service on VPG157, error 5 while opening SCManager: (Access is denied.)
-
We\'re starting to understand this issue more and more. I take it you\'re on a domain, is that correct? And if so, are the Win7 machines you\'re trying to scan on the same domain as the machine you\'re scanning from?
-
This was all fixed for me in the last two releases. I forget exactly which but maybe 175. Forcing the app to use the credential manager when run from a win7 machine scanning a win7 machine. All works great in the latest release.
-
Godwin, you\'re saying you must force Newt to use domain credentials and that both remote Win7 and the PC you\'re scanning from is on the same domain?
-
I am saying that my problem was fixed by the last couple releases (see 175 notes). Scanning from a win7 machine to 3 different domains or the same domain works fine now in the latest release. I found (as in above) that the service was trying to install using the crendentials I was logged in as instead of the ones specified in the credential manager. It works for me now using the latest version of the software.
I worked out the problem with Jim in support or development.
I was getting error 6 but superguyent gets error 5, the symptoms are pretty much the same though.
-
And thank you very much for your help too!
Yes, we changed the way the error is reporting. That\'s why he\'s getting an error 5 instead of an error 6 So you\'re correct, it\'s basically the same error.
It makes sense that trying to scan a different domain would cause the error as it used to, but I guess what I\'m asking is, and just out of curiosity: when you scan your own domain, do you have to put in domain credentials, or are you already a Domain Admin of your domain and therefore don\'t need credentials?
-
I am already a DA in my domain but still use alternate credentials for the scans. It does pass the alternate ones I specified in the manager.
-
So the credentials you supply in NEWT are the same credentials as your DA account or are they different DA credentials? Different meaning a completely different username/password than the DA credentials you\'re already logged in with.
And if they are different, are you only doing it this way because you couldn\'t scan your own domain\'s Win7 machines successfully with NEWT even though you\'re a DA on your domain? Because if you are a DA on your domain, you shouldn\'t need to be supplying alternate DA credentials for scanning. And if so, it\'s something we need to look into further.
Thanks again for your help!
-
I don\'t have any problems. I was just trying to help the other guy superguyent. I can use either my own or specify different ones. A personal preference not to use the DA as logged on, wanted to use another. Yes it works both ways just fine.
-
No, I understand yours is working fine. I was just wanting to understand how you had yours set up to make sure we\'re not missing something.
So you\'re saying if you were to log yourself in as the DA on your domain, you wouldn\'t need credentials to scan Win7 PCs on your own domain, is that right?