From: Richard Passey on 23 Sep 2009 03:19 Hi All, We have an odd problem following the SP2 Exchange 2007 update. Since the update OOF messages can be set but the server does not send them out. This only occurs from OWA 2007 and Outlook 2007 clients. Those users setting OOF messages via the 2003 Outlook client work perfectly. We've tried all the different options in 2007 OOF preferences and none of them seem to make any difference. Our environment is 3 Exchange servers in one site spread accorss 2 domains; 2 are 2003 and the newest is 2007, we are due to decommision the 2003 servers shortly. Anyone have any suggestions? RIic
From: Shawn Brown on 24 Sep 2009 10:54 We have the same OOF problem, except none of our OOF messages go out. One Exchange 2007 server and a mix of Outlook Clients. When I use MCPMapi to look at the PR_OOF_STATE, setting up OOF in Web Mail or Outlook 2007, does not change the STATE to True. Setting up OOF in Outlook XP DOES change the STATE to True, but no response is actually sent. I tried all 4 of the settings in the Exchange Management Console -> Org -> Hub Transport -> Remote domain -> Default -> Properties. Shawn
From: Richard Passey on 24 Sep 2009 11:08 I think the PR_OOF_STATE setting applys the the 2003 legacy OOF. But I could be wrong. I'm going to have to stomach the �200 and open a call with Microsoft as non of the exchange consultants round here can figure out what the problem is. Ric "Shawn Brown" <shawnbrownjunk(a)gmail.com> wrote in message news:f3893f71-f7e8-48c6-86e7-f7d18638b305(a)g23g2000vbr.googlegroups.com... > We have the same OOF problem, except none of our OOF messages go out. > > One Exchange 2007 server and a mix of Outlook Clients. > > When I use MCPMapi to look at the PR_OOF_STATE, setting up OOF in Web > Mail or Outlook 2007, does not change the STATE to True. Setting up > OOF in Outlook XP DOES change the STATE to True, but no response is > actually sent. I tried all 4 of the settings in the Exchange > Management Console -> Org -> Hub Transport -> Remote domain -> Default > -> Properties. > > Shawn > > >
From: Richard Passey on 25 Sep 2009 06:28 I think I have got to the bottom our issue; We're not entirely sure what fixed it. We think it was related to 9040 errors which in MS land point to a mismatch between the server DN and the user DNs. We thought this could be a problem with some legacy uses still on a 2003 server so we moved these over to our 2007 server on a new archival database. This did not fix the problem and the 9040s persisted. We noticed that 2 legacy mailboxes remained, even though they we on the 2007 server. To fix these we moved them to a different storage group and back again (and then performed the set-mailbox *** -setmandatoryattributed in the shell). This changed the mailbox type back to the standard "user mailbox". This seems to kill the 9040 messages and return Out of Office OOF functionality for all mailboxes. How did these legacy mailbox become legacy mailboxes? We have been creating 2003 accounts using a vbs script (along with the AD account, shares, aliases etc). Seems that this script is insufficient for use in our 2007 SP2 architecture. We haven't tested this yet but looks like additional AD values are required. We can set and manually reset these values in ADSI too. ' Specific Exchange 2007 attributes required to ensure mailbox is created successfully exchangeVersion = "4535486012416" msExchRecipientDisplayType = "1073741824" msExchRecipientTypeDetails = "1" ' Build and write the users Exchange attributes (that we used for 2003) oNewUser.put "mDBUseDefaults", sLDAPmDBUseDefaults oNewUser.put "mail", lcase(EmailAlias) & "@" & sParentMaildomain oNewUser.put "msExchHomeServerName", sLDAPExchangeServer oNewUser.put "mailnickname", lcase(sLogon) oNewUser.put "homeMDB", sLDAPhomeMDB oNewUser.put "displayNamePrintable", lcase(sLogon) ' Specific Exchange 2007 values required to ensure mailbox is created successfully exchangeVersion = "4535486012416" msExchRecipientDisplayType = "1073741824" msExchRecipientTypeDetails = "1" ' Exchange 2007 specific ad properties that need settings oNewUser.put "msExchVersion", exchangeVersion oNewUser.put "msExchRecipientDisplayType", msExchRecipientDisplayType oNewUser.put "msExchRecipientTypeDetails", msExchRecipientTypeDetails Problem is we can't seem to break Out of Office now? Potentially it could be that only accounts made before sp2 with our script were causing the issue. Simply running our bad script doesn't return us to 9040 errors and no OOF (although it does make "legacy mailboxes". If I get a better analysis of the fix/problem I will post it here later. I but this info here to inform and perhaps assist with other facing loss of OOF function. If you'd like to contact me for support on this matter directly my second name at gmail will get you to me. I guess it's about time we changed to powerShell! Ric Passey "Richard Passey" <r.passey(a)ucl.ac.uk> wrote in message news:eHdeVjSPKHA.4700(a)TK2MSFTNGP05.phx.gbl... >I think the PR_OOF_STATE setting applys the the 2003 legacy OOF. But I >could be wrong. > > I'm going to have to stomach the �200 and open a call with Microsoft as > non of the exchange consultants round here can figure out what the problem > is. > > Ric > > > "Shawn Brown" <shawnbrownjunk(a)gmail.com> wrote in message > news:f3893f71-f7e8-48c6-86e7-f7d18638b305(a)g23g2000vbr.googlegroups.com... >> We have the same OOF problem, except none of our OOF messages go out. >> >> One Exchange 2007 server and a mix of Outlook Clients. >> >> When I use MCPMapi to look at the PR_OOF_STATE, setting up OOF in Web >> Mail or Outlook 2007, does not change the STATE to True. Setting up >> OOF in Outlook XP DOES change the STATE to True, but no response is >> actually sent. I tried all 4 of the settings in the Exchange >> Management Console -> Org -> Hub Transport -> Remote domain -> Default >> -> Properties. >> >> Shawn >> >> >> > >
From: Shawn Brown on 25 Sep 2009 20:26
I'm sure our issues are totally unrelated, but in case someone happens upon this thread, I wanted to post the solution to our OOF problem as well. We fixed our OOF issue by following the info in this link about "The System Attendant homeMDB attribute is missing". We should have re-ran the Best Practices analyzer after installing SP2. http://technet.microsoft.com/en-us/library/dd535374.aspx Shawn |