Posts from — April 2008

This mysterious message was well documented by Microsoft.

Everyone knows that any user in a domain, even down to the user with least privileges, is able to connect to a network shared printer, right?

That is what I thought, until one of my users tried to connect to a shared printer and got the following error message:

Other users on my network can connect to shared printers with no problems. I did not remember creating a group policy to cause this. What is going on?

I found a Microsoft Knowledge base article (888046) with the answer. The first cause mentioned is trying to install a third party driver. Although the driver is from HP, I have never had this problem before with HP. The second cause had to do with the DNS setup. In my case, for this subnet, I did not have the DNS reverse lookup zone configured properly. To fix the problem quickly, I gave the user administrative permissions to the local computer and he was able to connect to the shared printer. I also created a reverse lookup zone for this subnet to solve what I believe was the main cause of my problem.

From time to time, I would like to highlight mysterious error messages that I have received and the solutions that fixed it.

I have a trust with another domain. A developer, with a user id in my domain, asked for access to a share on the web server in the other domain. I went to the web server and I added the developers group (which was a global group in my domain) to the share and the NTFS permissions.

The developer, with the proper share and NTFS permissions, should have access to the server, right?

I thought so. But the developer called me and told me that he could not connect. I added my non-admin user id to the developers group. I couldn’t get in either.

So, to the command prompt I go. I typed in a net use command to connect to the share. BREAKTHROUGH! An error message is returned. It read as follows:

Logon Failure:  The user has not been granted the requested logon type at this computer.

Doing a little research, I discovered that the error had to do with the user rights. Even though I had a valid trust relationship, valid share permissions, and valid NTFS permissions, the developer still lacked the user right to "Access this computer from the network."

To fix this problem:

1. Go to Start-Administrative Tools-Local Security Policy

   

2. Under Security Setttings, expand Local Policies and click on User Rights Assignment.
3. On the right side, modify the Access this computer from the network policy by double-clicking on it.
   
4. Click on the Add User or Group button to add the user or group to the policy. Click OK to save.

Since installing Service Pack 1 for System Center Essentials (SCE), almost all of my computers are reporting the following error:

“Performance Module could not find a performance counter”

This is extremely annoying because it looks as though all of my clients are in trouble.

I have not been able to find much support for System Center Essentials and this issue. However, over on the blog for SCE’s big brother, System Center Operations Manager, there is a workaround for this same issue for their Service Pack 1. The instructions work for SCE as well.

Note that this is only a workaround. Microsoft still needs to provide a permanent fix which may entail updated Management Packs.

1. Navigate to the Authoring Space in the Console.
2. Select “Rules” under “Management Pack Objects”.
3. Type “Performance Data Source Module” in the “Look for:” box and click “Find Now”. Be sure a Scope is not set or filtering the “Health Service” Target.
4. Find the rule, “Performance Data Source Module could not find a performance counter” under “Type: Health Service (2)”*, right-click, select “Overrides”, “Disable the Rule”, “For all objects of type: Health Service”.
   *Note: In my installation, I only had “Type: Health Service (1)”
5. When prompted, “Are you sure you want to disable this rule for Health Service?” click “Yes”.

This should minimize your headaches until Service Pack 2 is released.