Tips for Getting Better Support

Posted on by
Reply

Getting a technical problem resolved can be a frustrating and time-consuming process, for both the end user who is needing help, and for the support personnel trying to provide assistance. But there are a few basic steps that the end user can take to help streamline the process, resulting in a better experience for all concerned.

Find out if what you are experiencing is a known problem. If you are having trouble accessing a service, check the relevant status page to find out if the administrators are already aware of the issue and working on it.  Some service providers will have a status website to provide this information, others will provide notifications via mailing lists. (Here at UT, status updates for ITS services are provided at http://www.utexas.edu/its/alerts/.) If the administrators are already aware of the problem and are working on it, further notifications that “Server X” is down don’t really help. But if there is no indication that the administrators are aware of the issue, then certainly let them know of the problem through the relevant channels. If you are encountering a problem with software, take the time to check the relevant documentation and/or consult a search engine to find out if you are dealing with a known bug. In the process of doing so, you might encounter information about workarounds or bug fixes. Google really is your friend here. If you are running into a problem, odds are that someone else has as well.

At the risk of sounding repetitious, but it is an important point, read the relevant documentation. Frequently, there will be troubleshooting guides available that will help you solve many simple, commonly-encountered issues. This frees up support resources to work on issues that aren’t documented.

When reporting an issue, be specific. Saying “I can’t get to Server X” or “E-mail isn’t working” isn’t enough information for troubleshooting.  What is the actual text of the error messages that you getting? What exactly were you trying to do when the problem occurred? What client software and version are you using? What OS version are you using? When did you first notice the problem? When did it last work correctly? Have you made any changes on your end just before the problem cropped up, such as installing a piece of software or changing your configuration? If you are requesting a restore from backup, when was the missing data last known to be present? Being vague in your request for assistance only results in lengthening the time that will have to be spent subsequently gathering the needed information.

Communicate. If the support staff request further information, please respond.  If they ask you to try something, follow-up with information about whether it worked or not.  (If the suggested fix DID work, the support staff need to know so that they can close out your support ticket.) Otherwise, your support ticket will languish in the queue while support staff work on other issues.

Recognize that there are limits to what your support staff can do. For example, if you are encountering a bug in your software for which the developer has not issued a patch, the best that can generally be hoped for is a workaround. As another example, I am frequently asked to do mailbox restores so that a user can recover a missing crucial message, but what users tend to fail to grasp is that I cannot actually see the contents of the backups.  You need to tell me when the missing data was last present so that I can select the appropriate backup. (This is not the case for all backup solutions, but, alas, it is the case for the one we are using.) We are not deities. We do not have access to the source code of Windows. We do not have a magical “fix all my problems” button. But we will do what we can.

Calendar Sharing Permissions Bug in Entourage Web Services

Posted on by
Reply

I’ve long been aware that Entourage does not know how to properly handle the granularity of control over free/busy information introduced by Exchange 2007, but I’ve now become aware of an even more serious bug on this front in Entourage 2008 Web Services Edition. It seems that anytime that version of Entourage is used to modify Calendar sharing permissions on an Exchange 2007 server (and presumably an Exchange 2010 server), the user or group to whom the permissions are being granted looses the ability to see the free/busy information for that Calendar, regardless of the permissions level granted.

Here are the steps that I have taken to replicate this issue in our environment.  We have Exchange  2007 SP1 Rollup 8. In the testing which I describe below, I am using Outlook 2007 and Entourage 2008 Web Services Edition, Version 13.0.03  (091002). Steps to reproduce the issue are as follows:

  • – In Outlook, grant sharing permission to another user on your Calendar. For this example, we’ll grant the user “Free/Busy time, subject, location” permissions. Verify that on the permissions tab, with that user selected, in the Read section, the radio button  for “Free/Busy time, subject, location is checked. After clicking “Apply”, verify that the user can in fact see your free/busy. We have now set a baseline for expected functionality.
  • – Now, in Entourage, check the sharing permissions on your Calendar. For the user to whom you have granted permissions, the permissions level will show as “None.”  Now let us use Entourage to modify the sharing permissions. Set it to “Reviewer” for example, and click “OK.”
  • – At this point, the user to whom permissions have been granted will be unable to see your free/busy information. (This is true regardless of what permission  level is set in Entourage.)  Looking at the Calendar sharing permissions in Outlook, none of the Read permission items are checked.

This is a serious bug in Entourage, and the only way that I know of to repair the damage is to properly set the permission with an Outlook client.

UPDATE (Sept. 15): We received a note from Cornell indicating that they found that applying Service Pack 3 fixed this issue. Thanks for the heads-up. We are at SP2 RU4, and the problem still manifests at that patch level.

Addition in PowerShell

Posted on by
Reply

In general, PowerShell is able to detect when a mathematical operation is being performed and convert strings on the fly to permit this:

PS C:\> $x = 10 + “20”
PS C:\> $x
30

However, there are cases where this does not always work as expected:

PS C:\> $x = “1000”
PS C:\> $y = $x + 500
PS C:\> $y
1000500

As you can see, instead of converting the value of $x to an integer and performing the expected addition, it simply treated the entire command as a string concatenation operation. Note, however, that subtraction works just fine:

PS C:\> $z = $x – 500
PS C:\> $z
500

Knowing this, combined with the fact that subtracting the negative of a value is the same as adding the value, we have a workaround:

PS C:\> $y = $x – (-500)
PS C:\> $y
1500

A more straightforward solution, however, is to force PowerShell to treat our variable as an integer:

PS C:\> $y = [int]$x + 500
PS C:\> $y
1500

Dealing with “Orphaned” Delegations

Posted on by
3

Every once in a while, we get a ticket complaining about meeting invites generating an NDR claiming that a mailbox (not belonging to any of the invitees) does not exist. Invariably, this turns out to be due to one of the invitees having a delegate whose mailbox has been deleted, and this can be a pesky problem to resolve.

Here is a summary of how the delegation process works under the hood, and how to deal with “dangling” delegations when mailboxes are deleted.

Suppose you have a mailbox for user A who wishes to make user B a delegate.  When the delegation is made the following takes place:

  1. Appropriate sharing permissions are placed on the relevant folders in user A’s mailbox, depending upon the permissions set with the delegation tool.
  2. If the checkbox for forwarding meeting requests is set, a special hidden forwarding rule is created in user A’s mailbox.
  3. User B is added to user A’s publicDelegates attribute (the send-on-behalf-of field), and user A is added to the publicDelegatesBL attribute of user B. This does not always happen in recent versions of Outlook, especially when the person trying to set the delegation is not actually the owner of mailbox A. See this earlier posting for more information on this issue.

    Unfortunately, if the mailbox for user B is deleted, their publicDelegatesBL entry in AD gets cleared out, so there is no direct way to track down who they might have been a delegate for. Even more problematic, when user B’s mailbox is deleted, the hidden forwarding rule in mailbox A does not get updated, which is why it is important to always remove someone as a delegate prior to their mailbox being deleted.

    Assuming that we can narrow down whose mailbox has the orphaned delegation, we can manually fix this by using the MFCMAPI tool to delete the hidden forwarding rule (the instructions being contained in the README file accompanying MFCMAPI). Unfortunately, if there are other delegates to that mailbox, the forwarding for them would break as well, so all of those delegates would need to be removed and re-added, which requires logging directly into the mailbox in question.

    If the owner of the problematic mailbox is okay with this, the Exchange administrators can go ahead and nuke that hidden rule from their mailboxe, but the mailbox owner will need to go in afterwards and redo their delegations, or the Exchange administrators could do that with their permission.

    Still More Exchange 2010 Goodies…

    Posted on by
    Reply

    Microsoft Forefront Protection 2010 for Exchange Server is now available. Capacity planning guidance for this product has also been published.

    Also of note is that Forefront support for the AhnLab, CA, and Sophos engines is being retired on Dec. 1, 2009. The new set of available scan engines will be Authentium, Kasperky, Microsoft, Norman, and VirusBuster.

    The only piece now missing is a 2010-friendly version of DPM for backing up Exchange.

    The Latest Exchange 2010 Goodies

    Posted on by
    Reply

    Exchange 2010 RTM bits have been made available for download. Weee!

    Also, the Exchange 2010 Mailbox Server Role Requirements Calculator is out and I’m reading through the documentation on it now. (Now for a comparable tool for scaling CAS and HUB deployments and we’ll be all set.)

    But wait, there is more. The Exchange Server 2010 Deployment Assistant has also been released. This is basically a wizard which asks questions about your environment, and creates deployment checklists. Very helpful, far more so than trying to wade through the mountains of TechNet docs to create such checklists (which I remember vividly doing for our transition to Exchange 2007). On the downside, the current release is only for transitions from Exchange 2003 to 2010. A version which includes transitioning from 2007 is slated for release in early 2010.

    Of more immediate interest to the UT community, after I (along with our storage guru, Alex Barth) had spent most of last week cobbling together a preliminary plan for transitioning AEMS to Exchange 2010, we met with a Dell consultant for a whiteboard session to go over options for such a transition. Although there was not much depth to the session, the consultant did bring to our attention some ideas we had not really considered, so now we have more food for thought and testing to perform. My plan may very well undergo significant rewrites, but that’s okay. Actual deployment is a long way off, which gives us ample time to refine our plan so that, hopefully, it will go off with a minimum of problems.