Posts Tagged ‘Active Directory’

No tool like an old tool

March 7th, 2012 No comments

Administration Tools Pack gets a refresh

and Server Administration Tools

Another eNerd called me yesterday wondering how to let a non-admin user at his client’s business have access to their virtualized server. The hope was to have the vSphere Client locked down in some way.

When I asked what the user needed to do, it was “Manage users and reset passwords and such.”  I realized then that this was not a VMware access issue at all, but a Windows Server rights issue.

In fact, this can readily be handled by the Microsoft Management Console (MMC) which can be installed on the user’s workstation – no need to give the user login to the Windows or VMware server at all.

This is not a new trick by any means, but is one worth remembering.

Also, I’ll add that there is now a version for Windows 7 (Win7) and Vista, in both 32 and 64 bit flavors. (Sorry, they don’t let this run on “Home” editions of Windows.)  The following give some details.

There are many places where you can get detailed help on using MMC such as this post:
Here’s just a bit then about getting started with the “new” version.

    1. In Windows 7, click on the start button, and type “mmc” (Win7 will find the MS Management Console) and press enter. It will create a blank console called Console1. Click on “File”, “Add/Remove Snap In…” and you’ll see NO snap-ins for AD user management. Close MMC and let’s go get that snap-in.
    2. Download and run the Remote Server Administration Tools for Windows 7 (32 and 64 bit) is at:
A help screen should open to give you further assistance.

  1. Basically, after installation, you access Programs and Features from the Control Panel, click on “Turn Windows features on or off”, and expand Remote Server Administration Tools to reveal all the tools.
  2. For the case mentioned, to obtain access to Active Directory Users and Computers (for password and other user information), I drilled down into Role Administration Tools until I found “AD DS Snap-ins and Command-line Tools”. Check it and click OK
  3. Back to Win7, click on the start button, and type “mmc” and press enter. It will create a blank console called Console1. Click on “File”, “Add/Remove Snap In…” and you’ll see one for Active Directory Users and Computers. Click Add-> and OK and you’ll have your Management Console well on it’s way.

See the TechNet article for additional steps such as linking it to the Domain Controller, Saving the Console, etc..

Level Platforms install does it all, but must add MWService to admin groups

March 7th, 2012 No comments

While installing Level Platforms (LPI) Onsite Manager onto a Windows Server 2003 (a member server running on as and ESXi guest and added to a SBS 2003 domain) all went well, but one service would not start. Final, solution was that the MWService account did not have sufficient permissions. LPI tech support said to add that account to Administrators, Domain Administrators and Enterprise Administrators. This solved the problem.

After installation and during the registrationI entered my VAR domain and clicked Register, I received the message, “Unable to start Windows Service OMNetworkService.” When I ran services.msc and tried to start the OMNetworkService service, it attempted to, but then reported: “Could not start the OMNetworkService service on Local Computer. Error 1053 The service did not respond to start in a timely fashion.

Located the other LPI service, MWExpertSystem.  That service was running, but I restarted it and the started OMNetworkService. I still received the same error that it could not be started.

I consulted the LPI forums and found some suggestions that I make sure the MWService account be flagged as “Password never expires.” It already was.

I also checked the Local Security Policy and found that the MWService account WAS listed under the “Log on as a service” right.

I rebooted the Onsite Manager as a test and it came up with the message you’ve seen at server rebooting saying that some serices could not be started.

I attempted to use the OMTools – Stop OM Services + Start OM Services. Didn’t work.

I attempted stopping MWExpertSystem and starting OMNetworkService first. Didn’t work.

When I checked the Application log I found a .net error:

Event Type:    Error
Event Source:    .NET Runtime 2.0 Error Reporting
Event Category:    None
Event ID:    5000
Date:        12/17/2008
Time:        8:15:36 AM
User:        N/A
Computer:    MEMBER1
EventType clr20r3, P1 omnetworkservice.exe, P2, P3 48ca784e, P4 mscorlib, P5, P6 471ebc5b, P7 e4, P8 10, P9, P10 NIL.

An issue with .net. Considered working down that line, but eNerd Chris Polis, contacted LPI support.
LPI support tech Paul Savoie wrote:

Event ID 5000 is usually indicative of a rights issue with the account used for the services. Can you please have your tech confirm that the MWSERVICE account is a member of Domain Admin, Enterprise Admin, and Administrators groups.
A quick test to confirm this is the use the domain admin account for the service and see if it starts up correctly.

I did not try the latter, but made changes to the MWService account. Rebooted the server for good measure and the services fired right up.

Other comments from LPI (Jocelyn Sirois) regarding SBS setup:

Make sure the MWService account is added to the SBS group that is allowed access to the Internet. The LPI installation cannot do this. This is a default group created by the SBS default installation.
Verify that the logon credentials for the OMNetworkService  are the correct one.
If using ISA there are other considerations for some of the protocols.
The File and Print services on the SBS server must be enabled.