Jim-Doyle.com

Public folders are no longer mail-enabled via the graphical interface of the Exchange Management Console in Exchange 2007. This task, as well as many others, are carried out using the Exchange Management Shell command-line interface (CLI). I had to perform this task last week and had to look up the steps beforehand. I am adding them here for future reference but hope this post is of value to others as well.

The first step is to verify that the public folder that you want to mail-enable has not already been enabled. This is accomplished with the Get-MailPublicFolder cmdlet. The syntax is as follows:

Get-MailPublicFolder -Identity “YourPublicFolderName”

Next you need to disable the Email Address Policy for the public folder (the same as unchecking the Automatically update email addresses based on email address policy in the Exchange Management Console). This task is accomplished using the Set-MailPublicFolder cmdlet as follows:

Set-MailPublicFolder -Identity “YourPublicFolderName” -EmailAddressPolicyEnabled:$FALSE

Once you have confirmed that the public folder is not already mail-enabled and have excluded the folder from the Email Address Policy, you mail-enable the folder with the Enable-MailPublicFolder cmdlet:

Enable-MailPublicFolder -Identity “\YourPublicFolderName”

Now you are ready to assign the email address(es) to the public folder.  Again, we use the Set-MailPublicFolder cmdlet:

Set-MailPublicFolder -Identity “YourPublicFolderName” -EmailAddresses address1@contoso.com,address2@contoso.com,address3@contoso.com

The first address listed in the above cmdlet is automatically designated as the Primary SMTP address for the folder. If needed, you can change the primary address as follows:

Set-MailPublicFolder -Identity “YourPublicFolderName” -PrimarySmtpAddress PrimaryAddress@contoso.com

If you want to grant Send As permissions in Exchange 2010, you can use the Manage Send As Permission Wizard. In the Exchange Management Console, right-click the desired mailbox and then select Manage Send As Permission from the pop-up menu. In the Manage Send As Permission Wizard, click Add, and then use the Select Recipient dialog box to choose the user or users who should have this permission. To revoke this permission, select an existing user name in the Security Principal list box and then click Remove. Click Manage to set the desired Send As permissions.

An option to the Manage Send As Permission Wizard is the Exchange Management Shell. In the Exchange Management Shell, you can use the Add-ADPermission and Remove-ADPermission cmdlets to manage Send As permissions. The syntax of the Add-ADPermission cmdlet is as follows:

Add-ADPermission -Identity UserBeingGrantedPermission -User UserWhoseMailboxIsBeingConfigured -ExtendedRights ‘Send-As’

The following example of the Add-ADPermission cmdlet grants my user account Send As permissions to John Public’s mailbox:

Add-ADPermission -Identity ‘CN=Jim Doyle,OU=Engineering,DC=contoso,DC=com’ -User ‘CONTOSO\jpublic’ -ExtendedRights ‘Send-As’

The permissions granted above are removed using the Remove-ADPermission cmdlet.  The syntax of this cmdlet is listed below:

Remove-ADPermission -Identity UserBeingRevokedPermission -User UserWhoseMailboxIsBeingConfigured -ExtendedRights ‘Send-As’
-InheritanceType ‘All’ -ChildObjectTypes $null -InheritedObjectType $null -Properties $null

The following example of the Remove-ADPermission cmdlet revokes the permission assigned above with the Add-ADPermission cmdlet:

Remove-ADPermission -Identity ‘CN=Jim Doyle,OU=Engineering, DC=contoso,DC=com’ -User ‘CONTOSO\jpublic’ -ExtendedRights ‘Send-As’
-InheritanceType ‘All’ -ChildObjectTypes $null -InheritedObjectTypes $null -Properties $null

In my previous post, I concluded by saying that my next post would cover Send As permissions in Exchange 2010; however, I am going to slip this one in first.

Recently we discovered that we were not collecting disk performance data from one of the remote servers we manage with Operations Manager 2007.  Disk performance counters are enabled by default on all Windows operation systems after Windows 2000.  As this particular server is running Windows Server 2003 Small Business Server, I initially assumed that the counters were enabled.  I attempted to rebuild the performance counters from an elevated command prompt by running lodctr /R from the C:\WINDOWS\System32 directory.  Still no disk performance counters in Operations Manager 2007.

After a bit of research using my new best friend Bing, I was led to check the following registry key on the remote server:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PerfDisk\Performance

If present, locate the Disable Performance Counters value in the details pane.  If the data value is 0, the counters are enabled and if the value is 1, the counters are disabled.  In our instance, this value was set to 1 as shown below.

After changing the value, a reboot of the server was necessary for the operating system to reload the registry and pick up the change.  Our Network Operations Center (NOC) rebooted the server during the overnight maintenance period.  The following morning I check the Operations Manager 2007 Console and still had no disk performance counters.  I logged back onto the remote server and attempted to rebuild the performance counters from an elevated command prompt as outlined above.  Back in the Operations Manager Console, there were now ten performance counters available for each logical disk.

The moral of this story – first check the registry for the existence and setting of the key listed above, reboot the server, and then rebuild the performance counters.  Hopefully, this information will save someone else some troubleshooting and research time.

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.