An Exchange administrator occasionally must grant a user access to another user’s mailbox. In Exchange 2010, there are a couple of ways to accomplish this task. For those who prefer a graphical experience, the access permissions can be granted with the Manage Full Access Permission Wizard.

An alternative method is by running the Add-MailboxPermission cmdlet in the Exchange Management Shell, the command line interface for administering an Exchange 2010 server. The syntax of the cmdlet is as follows:

Add-MailboxPermission -Identity UserBeingGrantedPermission -User UserWhoseMailboxIsBeingConfigured -AccessRights ‘FullAccess’

The following example of the Add-MailboxPermission cmdlet grants my user account full access to John Public’s mailbox:

Add-MailboxPermission -Identity ‘CN=Jim Doyle,OU=Engineering,DC=contoso,DC=com’ -User ‘CONTOSO\jpublic’ -AccessRights ‘FullAccess’

In order to revoke the full access permissons assigned above, an Exchange administrator would run the Remove-MailboxPermission cmdlet in the Exchange Management Shell:

Remove-MailboxPermission -Identity ‘UserBeingGrantedPermission’ -User ‘UserWhoseMailboxIsBeingConfigured’ -AccessRights ‘FullAccess’ -InheritanceType ‘All’

The following example of the Remove-MailboxPermission cmdlet revokes my user account’s full access permissions to John Public’s mailbox:

Remove-MailboxPermission -Identity ‘CN=Jim Doyle, OU=Engineering,DC=contoso,DC=com’ -User ‘CONTOSO\jpublic’ -AccessRights ‘FullAccess’ -InheritanceType ‘All’

In my next post, I will show how to grant a user Send As permissions using the Exchange 2010 and the Exchange Management Shell.

We have had a problem at ClearPointe getting an Operations Manager agent to install on one particular remotely managed server. Attempts to push an agent with the OM Discovery Wizard would fail with the following error:

One or more computers you are trying to manage are already in the process of being managed. Please resolve these issues via the Pending Management view in Administration, prior to attempting to manage them again.

The server does not appear in Pending Management of the Administration space, nor anywhere else in the Operations Manager Console for that matter. 

After making one final attempt to push an agent today, I decided to note the error message and place a post on the Microsoft Partners newsgroup.  Before logging onto the newsgroup site, I tried one last Bing search on the error message.  I came across a post on Kevin Holman’s OpsMgr Blog that I had not seen previously and it described our issue exactly.

Pending action information is stored in the agentpendingaction table of the Operations Manager database and it is possible for this table to get out of sync with the console.  Normally, this will happen if an agent install or upgrade process crashes or is terminated before it completes.  Subsequent attempts to install an agent fail with the above error due to this synchronization issue.

The first troubleshooting step is to check the agentpendingaction table of the Operations Manager database for the presence of a row that references the “ghost” pending action.  Run the following SQL query against the Operations Manager database:

select * from agentpendingaction

Next use the Operations Manager powershell to attempt to reject the “ghost” pending action.  Open the command shell with elevated privileges and run the following, replacing servername.domain.com with the appropriate FQDN:

get-agentPendingAction | where {$_.AgentName -eq “servername.domain.com”}|Reject-agentPendingAction

At this point, an exception might be returned in the command shell, which is exactly what happened in my case.  There is one last resort, albeit not supported, so run this at your own risk.  There is a stored procedure in SQL that will delete pending actions.  Run the following query against the Operations Manager database:

exec p_AgentPendingActionDeleteByAgentName ‘agentname.domain.com’

Again, substitute the appropriate agent name as it appears in the SQL table in place of agentname.domain.com.  The stored procedure worked for me without issue.  I was then able to push an agent to the remote server using the Discovery Wizard and am happy to report that the remote server currently has a status of “Healthy” in the Operations Manager Console.  Thank you again, Kevin Holman!

I cannot take credit for making this discovery. Fellow ClearPointe engineer Noel Hall came across a post on the CNET News website and shared the link with the rest of us and I am taking this opportunity to share it with you.

Windows 7 has a hidden feature affectionately named “GodMode” which lets a user access all of the operating system’s control panels from within a single folder. To enter “GodMode”, all one needs to do is create a folder and rename it to the following:

GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}

Once renamed, the folder icon will change to resemble the Windows 7 Control Panel icon and will contain dozens of control options as shown below (note that there are actually 287 items in the shown below folder).

CNET News notes that “GodMode” is said to work in Windows Vista as well, although it can cause 64-bit versions of the operating system to crash.

“GodMode” is a neat little Windows 7 trick that can be very advantageous to anyone who regularly tweaks his or her operating system settings.

Welcome to my new Web site/blog hosted by Bluehost.com.  All of the posts and comments from my original WordPress blog have been imported into this site.  I am also in the process of moving content from my long-standing Web site www.jimdoylemcse.com, which I hosted on a Web server at my home and have now taken down.  As with the previous sites, the majority of the content on this new site will be computer-related, as these infernal machines occupy much of my time and put food on the table.  In addition to the geek stuff, I will mix in some humor, photographs, and other items of interest.  Check back often and be sure to subscribe to my RSS feed.  Happy New Year, Everyone!

This past week I was remotely preparing a customer’s server for induction into our Managed Services offering at ClearPointe.  This process sometimes includes the need to copy files from one of our servers in Little Rock to the remote server.  The server that I was remoted into was running Windows Server 2008 which, by default, with the introduction of User Access Control (UAC) and other features, is more secure than any previous Microsoft operating system….but I think Microsoft might want to rethink the situation that I am about to describe! 

From within an RDP (Remote Desktop Protocol) session on the remote server, I accessed our server in Windows Explorer via UNC path, located the file that I needed to copy to the remote server, right-clicked and selected the Copy option from the menu.  I then navigated to the root of the C: drive on the remote server, which was where I wanted to paste the file.  I right-clicked and selected Paste from the menu…but received the warning dialog box below.

Now, I understand that it can be dangerous to copy and paste certain remote files to a server and such action is oftentimes a sign of malicious activity, but where is the “security” in telling me that I do not have permission to copy files to a particular location over the network but can paste into the Documents folder and then move it to the original desired location?  I guess it could deter a malicious individual if said individual just could not wait the additional 10 seconds that it would take to get his package to the desired location!

Last summer I had the opportunity to see one of the greatest blues guitarist in history, B.B. King, in concert in Little Rock.  Last night my daughter, Katie, and I saw one of the greatest rock guitarists of all time.  Peter Frampton and his band performed at the Arkansas Music Pavilion in Fayetteville, AR, and we had second row seats.  The concert had originally been scheduled for July 21 but was postponed because some the band’s equipment had been damaged during a severe thunderstorm at a recent outdoor concert and repairs were not yet complete.  The show was well worth the four week delay!

Peter Frampton

Before Frampton took the stage, a band called The Elms did a thirty-minute set.  This band was founded in 2001 and hails from Seymour, IN.  The Elms have become one of the most respected and consistent young rock & roll bands from the midwestern U.S., both on record and on stage.  Katie and I were quite impressed with these four young lads.  The band did a very respectable job of getting the crowd ready for Frampton.

At 8:00 sharp, after a 30-minute break while the roadies shuffled equipment, Frampton and his band took the stage.  Their set included all of the Frampton classics as well as a couple of tracks from his latest CD Fingerprints, which was released in 2006, and a couple of tracks from his upcoming CD which, according to Frampton, is currently about 80% complete.  The band included long-time bassist John Regan, who has been making music with Frampton for 30 years.  Rob Arthur manned the keyboards and did a great job of filling the big shoes of the late, great Bob Mayo.  Adam Lester joined Frampton on guitar, a position also formerly occupied by Mayo.  For drummer Dan Wojciechowski, the band’s newest member, the evening was a homecoming of sorts because he is originally from Fayetteville.

This was truly one of the best, if not the absolute best, concert that I have ever attended and having my daughter along made it even more special.  Frampton has a number of concert dates scheduled through the end of September.  Should he come to a venue near you, I highly recommend that you make every effort to attend.  I have posted photographs and a couple of brief videos from the show on my Facebook page and my website.  Feel free to take a look.

We recently performed an upgrade on one of the applications that we use to monitor and manage client servers and devices.  As a part of the upgrade  process, we decided to move the application from servers running Windows Server 2003 to new virtual servers running Windows Server 2008.   The application is configured with a series of tasks that run each day during the early morning hours.  The tasks run under an Active Directory user account created solely for the purpose of running these tasks and with only the level of privilege required to perform this action.

After the upgrade it was discovered that the tasks were no longer running.  I began to troubleshoot the problem.  From within the application, I could right-click on a task and select to run a test job from the pop-up menu.  The task completed successfully.  If I selected the option to start the job in the context that it was to run each night, it failed consistently.  So why were the test jobs succeeding when the actual tasks were failing?  I turned to good, old Google and quicky found the root cause of the problem.

I discovered that tasks run in Windows Server 2008′s Task Scheduler, by default, run only when the user is logged onto the server.  This was not the case with Scheduled Tasks in Windows Server 2003.  To remedy the problem, I accessed Task Scheduler on the new server, right-clicked on each task and selected Properties from the pop-up menu.  On the General tab of the task’s properties, I selected the Run whether user is logged on or not option as shown below, and then clicked the OK button.  Now the tasks run nightly as expected.

Task Properties in Windows Server 2008

Although this subtle change in the way tasks are run in Windows Server 2008 is an improvement from a security standpoint, it can cause some head scratching if you are unaware of the change.  I hope this post saves saves some administrators a little head scratching.

Sorry about the lack of new posts lately!  I was troubleshooting an alert in Operations Manager 2007 from one of the many servers we manage.  Research on the Internet did not reveal any resolution to this specific alert although I did find a couple of postings that were somewhat similar and led me down the correct path to resolution.  Hopefully this post will help others that are troubleshooting this same alert.

Event ID:  1228
Source:  ADAM
Type:  Error
Description:  System Monitor was unable to open Active Directory performance counters.  An attempt to query the following performance counter registry key failed.
Registry key:
SYSTEM\CurrentControlSet\Services\ADAM\Performance\First Counter
Additional Data
Error value:  2 The system cannot find the file specified.

Sure enough, on my problematic server there was not a First Counter key in the registry at the location listed in the alert.  The similar posts that I came across during my research indicated that there might be an .INI file for the performance counters located at C:\WINDOWS\System32.  I had already noticed that the registry location above contained a PerfIniFile string value with a value of adamctrs.ini.  I checked the System32 directory and found no such file.  A search of the C: drive located it at located it at C:\WINDOWS\System32\ADAM.

I opened a command prompt and sourced from the C:\WINDOWS\System32\ADAM directory and ran the following command:

lodctr adamctrs.ini

I then returned to the Registry Editor and, from the menu, selected View > Refresh.  Four new DWORD values, as shown above, had been created – First Counter (the one causing my alert), First Help, Last Counter, and Last Help.  Alert resolved!  Finding the resolution to the problem took longer than the actual correction of the problem.  Again, I hope this post will help someone else resolve this error in a timelier manner with less research involved.

Exchange Management Pack synthetic transactions can generate a lot of noise in the Operations Manager console because there are numerous components that can contribute to the problem (i.e, Exchange, Active Directory, IIS, etc.).  Once it has been verified that the problem is an Operations Manager Agent issue rather than an actual user-impacting issue, the alerts are usually disregarded until someone has a chance to dig in and do some troubleshooting.  Today is one of those days for me.

We have been receiving the following alert from a client Exchange server for a number of days and it was initially diagnosed as an agent issue:

MAPI Logon Failure
MAPI logon verification: Problem in accessing Directory
Service caused Logon failure Exchange Server: “SERVERNAME”
MDB:”First Storage Group\Mailbox Store (SERVERNAME)”
Mailbox:”SERVERNAMEMOM” Error: The information store could not
be opened. [MAPI 1.0 - [MAPI_E_LOGON_FAILED
(80040111)]]

I checked the usual settings – mailbox rights, mailbox security, mailbox access account credentials, etc. – and everything was configured properly.  However, one thing caught my eye while checking the properties of the test mailbox user account.  On the Exchange Advanced tab of the Properties dialog box (below), the Hide from Exchange address lists option was selected.

Exchange Advanced tab

This did not seem quite right to me, so I checked test mailbox account properties in a couple of other client domains.  This option was deselected on every account that I checked.  Apparently, at some point, someone had selected this option so the account, which is disabled by default when created by the Exchange Management Pack Configuration Wizard, would not appear in the Outlook Global Address List. I promptly deselected the option and monitored the Operations Manager event log on the server.  Within minutes Event ID 19980 was logged indicating that all attempted MAPI logins of test mailboxes on the server had succeeded.

As is so often the case, an overlooked checkbox or radio button was the root of the problem and an alert that had repeated hundreds of times was finally closed.  During my troubleshooting, I did not come across anything that referenced the Hide from Exchange address lists option, although it surely exists somewhere in cyberspace, so I hope this post is beneficial to others trying to resolve a similar issue.

I spent some time today troubleshooting an alert that we received in Operations Manager 2007 from one of the client SharePoint servers that we manage in our Operations Center.  The alert referenced Event ID 6398 which indicates that the execute method of a SharePoint timer job definition had thrown an exception.  I logged onto the client SharePoint server and looked in the Application event log and, sure enough, it was full of the following 6398 event:

Event Type:    Error
Event Source:    Windows SharePoint Services 3
Event Category:    Timer
Event ID:    6398
Date:        11/19/2008
Time:        1:05:53 PM
User:        N/A
Computer:    <ServerName>
Description:
The Execute method of job definition Microsoft.Office.Server.Search.Administration.IndexingScheduleJobDefinition (ID 03d6f1b3-879c-42d9-8921-3f14b9e5678f) threw an exception. More information is included below.

Retrieving the COM class factory for component with CLSID {3D42CCB1-4665-4620-92A3-478F47389230} failed due to the following error: 80070005.

The System event log contained numerous instances of the following DCOM error as well:

Event Type:    Error
Event Source:    DCOM
Event Category:    None
Event ID:    10016
Date:        11/19/2008
Time:        1:06:26 PM
User:        NT AUTHORITY\NETWORK SERVICE
Computer:    ATI-SHAREPOINT
Description:
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
{3D42CCB1-4665-4620-92A3-478F47389230}
to the user NT AUTHORITY\NETWORK SERVICE SID (S-1-5-20).  This security permission can be modified using the Component Services administrative tool.

This problem can be resolved by accessing the Component Services applet by way of Start > Administrative Tools > Component Services.  In the task pane expand Component Services, expand Computers, and expand My Computer, and click on DCOM Config.

In the details pane on right, locate and right-click on the OSearch application and select Properties from the menu.  On the OSearch Properties dialog box, click on the Security tab.  In the Launch and Activation Permissions section, select the Customize option and then click the Edit button.

OSearch Launch Permissions

On the Launch Permissions dialog box, add the NETWORK SERVICE user and grant it Local Launch and Local Activation permissions as shown above.  Click the OK button twice and then close the Component Services applet.  You should now have a much quieter and happier event log!