By: David Greve
Posted:
September 22, 2008 at 11:00 PM
One of the challenges I had more recently with a migration from GroupWise to Exchange was specifically with users existing in GroupWise and users that have been migrated from GroupWise to Exchange. The scenario is, when users still exist in GroupWise, how do they email users already migrated to Exchange? The best approach, with minimal impact to the users is to continue utilizing the GroupWise address book and to also not lose frequent contacts historical information.
The challenge with maintaining the existing address book is how we represent the users and how messages flow forward to Exchange. If you have experience with the GroupWise connector for Exchange 2003, you know that contacts appear within GroupWise for migrated users. Those contacts send all messages to the API gateway, created for this connector. Well, in Exchange 2007 (without Exchange 2003 coexistence) SMTP mail delivery is the most optimal approach, between coexisting environments.
Because we are using SMTP mail delivery, we wanted to forward all messages going to the old GroupWise mailbox, to the new Exchange mailbox. However, when this occurs, the message does forward to the Exchange mailbox, but appears as an attachment from that person’s mailbox. (Example, GroupWise UserA sends to migrated GroupWise mailbox UserB. UserB receives the email in Exchange, but looks like it came from themselves UserB.) GroupWise is unlike Exchange, in which you cannot setup forwarding on the mailbox, without it looking like a forwarded message.
We found a solution to work around this problem. Our solution was to use a “Flat Forwarding” option with GroupWise. Flat forwarding is supported on a GroupWise Internet Agent (GWIA), but not necessarily (easily) on a per user basis. Our initial thought on flat forwarding was to direct each Domain/PO to the flat forwarding GWIA, when the users were migrated. However, that wouldn’t work because we couldn’t always plan for everyone to be migrated in a single Domain/PO. So our work-around for this was to setup flat forwarding on a specific GWIA and to direct each mailbox to that PO, by adding the GWIA address to their forwarding address. As an example: in the GroupWise client, normally forwarding would be setup as such: forward to UserB@exchange.smtpdomain.com. To support flat forwarding, we added the following to the SMTP address: GWDomain.FFGWIA:UserB@exchange.smtpdomain.com. The GWDomain.FFGWIA is the domain in which the GWIA exists, followed by the Flat Forwarding GWIA connector.
By: David Greve
Posted:
September 22, 2008 at 10:59 PM
After recently deploying PerformancePoint Scorecards within SharePoint, we’ve noticed some client computers (end-users) could not connect to these scorecards. As an example, we have had a filter on the scorecard that would produce an error of: “No Selections available. Contact your system administrator for assistance. Contact the administrator for more details.” The scorecard also continued to say “Updating…”, after seeing this error on the filter.
While continue to diagnose this issue, we noticed that certain computers could access the scorecards, while other computers could not. In fact, we were able to determine that it really wasn’t necessarily a user, but a machine coupled with a user issue. After doing some research on Kerberos, we noticed that some users did not have the “@domain.com” field entered, within Active Directory. For whatever reason, this field was left blank for some users.
After populating this field, we made one other change that impacted how the machine connected to the network. We noticed that some workstations would not pass Kerberos tickets. It was discovered that these machines were logging on with cached credentials. The reason why they were logging on with cached credentials was due to the fact that the networking services did not initialize right away for these machines. We made a group policy change that enforced the computer to wait for the networking services, before authentication occurred.
After making these two changes the scorecards, once not available, were now accessible from any workstation and any user that was authorized to view them.
By: David Greve
Posted:
September 22, 2008 at 10:59 PM
While implementing a couple SCR solutions, I noticed a common error I have seen while reviewing the copy status of a SCR source and target Exchange 2007 server. I noticed this problem while monitoring the health of a SCR configuration, as an example, run the following command:
Ø Get-StorageGroupCopyStatus –Identity <SourceServer\StorageGroup> –StandByMachine <TargetServer> | FL
If you see storage group copy status showing “Failed” instead of “Healthy”, and SCR was functioning properly in the past, check to ensure all services are running properly on both servers. I’ve seen this problem a couple times and every time I have reviewed this problem it appeared to be the replication service not running or needed to be restarted. Our most recent experience has been with Exchange 2007 SP1 - Rollup 3, in which the services would not start and a work-around needed to be applied to start these services. This work-around can be located at: Exchange Server 2007 managed code services do not start after you install an update rollup for Exchange Server 2007
By: David Greve
Posted:
September 22, 2008 at 10:59 PM
While implementing a couple SCR solutions, I noticed a common error I have seen while reviewing the copy status of a SCR source and target Exchange 2007 server. I noticed this problem while monitoring the health of a SCR configuration, as an example, run the following command:
Ø Get-StorageGroupCopyStatus –Identity <SourceServer\StorageGroup> –StandByMachine <TargetServer> | FL
If you see storage group copy status showing “Initializing” instead of “Healthy”, check to ensure all services are running properly on both servers. You may want to consider restarting the Information Store and Replication service on both servers, if you continue to see this problem. Worst case scenario, you may have to recreate the SCR configuration for that storage group. Here is an example of how to perform those tasks:
Start by disabling SCR for the Storage Group in question:
Ø Disable-StorageGroupCopy <source server>\<SG in Question> –StandbyMachine <target server>
Recreate SCR for that Storage Group
Starting replication from the source server:
Ø Enable-StorageGroupCopy <source server>\<SG in Question> -StandbyMachine <target server> -ReplayLagTime 0.0:0:0 -TruncationLagTime 0.0:0:0
(*Note, set the replay and truncation lag time with the delay you previously defined.)
Ø Suspend-StorageGroupCopy <source server>\<SG in Question> –StandbyMachine <target server>
(*Note, the replication service may not respond, causing the command to not run successfully. You may have to wait five minutes before running this command.)
Seeding the target server:
Ø Update-StorageGroupCopy <source server>\<SG in Question> –StandbyMachine <target server>
Finalizing replication on the source server:
Ø Resume-StorageGroupCopy <source server>\<SG in Question> –StandbyMachine <target server>
By: David Greve
Posted:
September 22, 2008 at 10:59 PM
We have been deploying Exchange 2007 for a while now, on Windows Server 2003. Most recently, I have deployed Exchange 2007 on Windows Server 2008 machines. The one noticeable problem, while setting up the Client Access Server role on server 2008 was that the Offline Address Book(OAB) URL was not functioning properly. You could access the OAB directory, only after IIS has been restarted or after the server restarts. However, after a couple minutes, the site becomes inaccessible, with a permission error. This also presents a problem to the end-users, as it asks them to authenticate to the OAB URL over and over again, but never actually accepts their credentials. My initial work-around for this problem was to setup Basic Authentication with SSL. (which actually fixes the problem.)
I was not very satisfied with this work-around as NTLM should work with Exchange 2007 and Windows Server 2008. After working with one of my colleagues Erik Enger, who stayed in touch with Microsoft, we discovered what the root cause of this problem was. The problem seems to be related to Kernel-mode authentication. When it is not enabled, the problem with the OAB IIS folder seems to go away. We also applied these same settings to AutoDiscover and EWS folder. This resolved our OAB and Outlook Anywhere authentication issues, using NTLM. Before considering these settings for your environment; please review the security and performance implications in your environment, before accepting such changes.
|
|
|
|
 |
|
|
|
 Professional Services ManagerDavid Greve is the professional services manager in the Milwaukee, WI office for PointBridge. He has over 12 years of consulting experience in the IT industry, designing and implementing solutions for... [more]
|
|
|
|
|
|