Professional Insight

Technology consultants
Home
Contact Us
About Us
Site Map
Windows Vista
Exchange 2007
Microsoft Exchange 2007 - Lessons Learned

 
"username" is not valid for UserPrincipalName
by Al Degutis

After creating a couple of new mailboxes for existing user accounts, I started getting this message when I tried to create a few more:
Error: "username" is not valid for UserPrincipalName. Valid values are: Strings that includes '@', where '@' cannot be the last character..

Michael D'Angelo suggested I review the Account tab in Active Directory Users and Domains for a clue. What I found there was the domain name was missing next to the User Logon Name, thus make the UserPrincipalName incomplete:

 


Filling in the domain name by selecting it from the pull-down list fixed the mailbox creation error.

 

 
 
Setting up an automated response e-mail
Good for support@ type addresses 
 
 
  1. Create your support@ mailbox in Exchange 2007.
    1. You may also wish to set up forwarding on the account (Properties -> Mail Flow Settings -> Delivery Options -> Properties) to a distribution list or a specific person. For the auto-reply to work you must enable Deliver messages to both forwarding and the mailbox on that screen.
  2. Create an Outlook profile for this account.
  3. Go into Outlook and create a new rule:
    1. Sent to <person or distribution list>
    2. Have server reply using a specific message
      1. Create the reply message by clicking on a specific message.
      2.  
        Close the message to save it (it will be saved on the server)
    3. Save the rule
  4. You must make sure the replies are allowed:
    1. In Exchange Management console go to
      Organization Configuration ->
      Remote Domain tab ->
      Right-click and select Properties ->
      Select the Format of original message sent as attachment to journal report:
      Enable Allow automatic replies
 

 

 

Import-mailbox fails with "Non-matching max change numbers" in Outlook log entry
by Al Degutis

When I was trying to import mail into Exchange using Import-mailbox, it ran as if it worked (i.e. no errors), except that nothing was getting imported. The only clue was the following application event log message for Outlook:
Event Type: Information
Event Source: Outlook
Event Category: None
Event ID: 30
Date: 1/14/2008
Time: 2:46:02 PM
User: N/A
Computer:
Description:
The store c:\outlook\test-import.pst is being reconciled with the indexer for the following reason: Non-matching max change numbers.
The Exchange event log entries for the import simple stated "The import-mailbox task for mailbox 'A Degutis' finished."
 
Exporting data from an existing Exchange mailbox, and then importing that back in worked, so everything is set up correctly and does work... just not for our existing Outlook PSTs (Outlook 2003 and Outlook 2007) which were receiving mail from IPSwitch's iMail v8.22.
 
This issue is in the hands of Microsoft PSS. They have confirmed that the problem occurs when you try to import a PST that has picked up mail from a POP3 server. We utilize both POP3 and IMAP on iMail and both fail to import.
 
Microsoft developed and provided an Interim Update for Exchange 2007 (KB947391). Installing this interim update requires that strong name validation be disabled via a utility that Microsoft provided. As of today, there is no Microsoft knowledgebase article on this, at least not based on the number provided.
 
 [Last update: 2008-Mar-31]
 
 
Outlook 2003 will not connect to Exchange 2007
- Event ID 9646 "Mapi session exceeded the maximum of 32 objects of type session"
 
by Al Degutis

After adding a half-dozen users to Exchange, one user encountered a connectivity problem. It occassionally occurred when the user attempted to connect to Exchange while connected remotely to the VPN.
 
Outlook was reporting 0x8004011D "The Server is Not Available."
 
A few websites suggested deleting the Exchange Profile in Outlook (not the Windows User Profile!) and then recreating it. That did not fix the problem. Unable to find a solution after the first occurrance, we simply reboot the server.
 
After the second occurance, we dug deeper, researching the Event ID 9646 that was coming up on the server:
Event Type: Error
Event Source: MSExchangeIS
Event Category: General
Event ID: 9646
Date: 4/1/2008
Time: 7:46:41 AM
User: N/A
Computer: BEX1
Description:
Mapi session exceeded the maximum of 32 objects of type "session".
 
We ran the Microsoft Exchange Troubleshooting Assistant (ExMon isn't available for Exchange 2007). It reported:
High user RPC activity
Since the RPC operations per second per user is greater than 0.25, the RPC operations per second rates indicate a user or users on this server are unusually active. The measured RPC operations per second per user rate is 0.401.
It offered this help:
What to Do if the RPC Load Is High
If the operations per second are higher than expected, you should first attempt to identify the cause of high load and then reduce it. You can use the Exchange Server User Monitor (ExMon) tool to identify if a particular user is issuing a high rate of RPC operations.

If you are unable to reduce the load on the server, you must identify the performance bottlenecks and increase the capacity of the server.
This was concerning. If the server cannot handle a half-dozen users, how will it survive 125 employees? Also, as mentioned earlier ExMon is not available for Exchange 2007. Unfortunately, much of the Exchange 2007 help documention is from Exchange 2003.
 
Since this was only occurring for one person, we couldn't accept that is was a server performance issue. Further research came up with three possible solutions:
 
1. Give the affected user rights to view the information store status:
add-adpermission -Identity "username"  -user isi-info\accountname
-AccessRights extendedright -ExtendedRights "View Information Store status"
 
This didn't fix the problem.
2. Set the Maximum Allowed Sessions Per User to something higher than the default 32
We made the change to the register bumping it up to 128, but we didn't reboot. Not sure if the reboot was necessary, but we probably should have stopped and restarted the Exchange Information Store service. We didn't because we were not in our maintenance window. So we cannot say with certain if this would fix the problem, or just delay it.
3. Thinking that #2 would just delay the "exceeded MAPI sessions" problem, we disabled the TCP offloading on the server it can be done via registry (second item below) or via Netsh command (first item below), which is what we used since it didn't require a reboot.
  • Windows registry at:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
    Change the EnableTCPChimney value to "0".
    This requires a reboot.

 

  • Or you can do it from a command line without a reboot.
    "Netsh int ip set chimney DISABLED"

Disabling the TCP Offloading on the server via the Netsh command allowed Outlook 2003 to reconnect to the server. We're monitoring this to see if this is a permanent fix.

[Last update: 2008-Mar-31]