Exchange 2003 SP2 OWA not showing archived messages

[Pending_Shortcu]

Hi guys, getting the classic @65 bytes for attachments in OWA..using EV 6 SP1...the only thing a bit new for me here is that the customer is running Exchange 2003 SP2 on Backend only servers...also installed Exch 2003 SP2 Sys Man on the EV server.

Also, no Search or AE buttons or archiving, restore, etc buttons showing in OWA..so it looks like the Exchange server isn't communicating with the EV server...have checked proxycfg settings already.

Any known issues or anything extra that needs to be done for Exchange 2003 SP2? Archiving, restoring, etc works fine through Outlook.

Thanks

D

[TonySterling]

Make sure the backend exchange server is listed first in the proxycfg. I would go ipaddress and netbios name.

[Pending_Shortcu]

Thanks..did that but still the same thing. Checked the IIS logs on both the Exchange and EV servers...nothing shows up on the EV server coming from Exchange, but in Exchange IIS logs, I'm seeing 401.2 errors (access denied) using the vault admin account to test OWA

[Tremaine]

I presume that you have installed the V6 SP1 OWA extensions on top of the E2k3 SP2 installation.

Can you check that the control files have been updated correctly. Also make sure that all the EV virtual directories have script execution enabled. Also check the setup logs and make sure that the forms have registered correctly.

Try using a different test account for a user on the applicable exchange store.

Cheers

[Pending_Shortcu]

Thanks for the suggestions, but everything checks out...I even copied the EV controls files to the other controls directories for the base Exchange install and the SP1 install..and it is happening for other users as well...also seeing it on 3 other Exchange servers...all of them are E2003 SP2. EV icons show up for archived items, and the shortcut shows up in the preview pane, just can't open the message, no search or AE or archiving buttons, and attachment is @65B...

Network adapter on EV server and Exchange is teamed...not sure if it makes a difference, but when checking proxyconfig settings, it did put in a 0.0.0.0 IP addy in there for the one NIC that was disabled on the Exchange server. Not sure if this is related to access denied messages in the IIS logs on Exchange, but EV server isn't seeing anything coming from the Exchange server when accessing archived items (as I've looked at the IIS logs there as well to confirm that)

D

[Pending_Shortcu]

The other thing is that this is a back-end only server, and users are going directly to it for OWA, so they've created a cert to use SSL...I didn't think we needed to create a cert for us, but in this case, do you think we do?

Thanks guys...

D

[Tremaine]

One thing to make sure of is that the requirement to make use of SSL certificate on the EnterprisevaultExchange / Pulic and EVOWA virtual directories has not been set on the directory security. If it has you might see some 403 errors on these VD's and you will have to remove the setting:

Under the properties of the Virtual Directory go to Directory Security; Secure communications, click Edit. Make sure that Require secure channel (SSL) is not enabled, and then click OK

[Pending_Shortcu]

Nevermind..the cert's for the server, not a specific website...

IIS logs on Exchange shows getting access denied (401.2) when running commands like "GET /exchange/vaultadmin/ cmd=EVSettings"...anything related to EV looks like its getting access denied..

[Pending_Shortcu]

> One thing to make sure of is that the requirement to
> make use of SSL certificate on the
> EnterprisevaultExchange / Pulic and EVOWA virtual
> directories has not been set on the directory
> security. If it has you might see some 403 errors on
> these VD's and you will have to remove the setting:
>
> Under the properties of the Virtual Directory go to
> Directory Security; Secure communications, click
> Edit. Make sure that Require secure channel (SSL) is
> not enabled, and then click OK

Checked that, thanks...nothing was checked there, so that's ok...looks like the 401.2's we're seeing are normal..tested on my VMWare, so that's not it.

No errors when doing the forms registration during the extensions config, only throws warnings saying that the VD's already exist (after running the install a few times).

Looked again at the IIS logs on Exchange and even when doing a preview of the archived item, it doesn't ever go to the /enterprisevaultexchange VD as it does on my VMWare...it just stays on the /exchange virtual directory...

[Pending_Shortcu]

Ok, it looks as if the forms didn't get registered properly, even though we got no errors during the install...looking at the backend setup log shows that the program couldn't find the system mailboxes in AD...doesn't look like they have any system mailboxes..any way around this?Message was edited by:
Dan Littman

[Tremaine]

You can use an alternate mailbox to register the forms with. However you will have to do this on a store by store basis. The fact that they have no SystemMailboxes is a concern and the customer should get that resovled.

Run the script as such:-- cscript backend2003setup.wsf /formreg /formregmbx:Store1mailbox

Where Store1mailbox is the display name of a mailbox that resides in that information store on that server. The /formreg switch indicates that only forms will be registered, no other configuration will take place.

Cheers

[Pending_Shortcu]

Thanks, good to know. I directed the customer to get with MS to recreate their System Mailboxes and will follow up after.


Thanks again

D

[Paul_Harris]

I had the exact same problem which I have now fixed (with a little help from MS)
Within AD Users and Computers, view advanced features and select Microsoft Exchange System Objects.Within here there should be a 'schema-root' entry which was missing in our AD however it does exist within system folders viewed via Exchange System Manager. I carried out the following instructions from MS to fix the problem and now the @65 error is gone and OWA works just fine

Delete the schema root under System Folders in ESM

1. Run ADSIedit and connect to the configuration container, navigate to services\Micrsoft exchange
2. There drill down to the server object under the administrative group, expand the cn=InformationStore, cn=storage group. Now you should see the CN=Mailbox Store and CN=Public Folder Store on the right.

3. Right click and get properties of the public folder store, look for the msExhFirstInstance attribute? and set it to true.

4. Now run regedt32 and go to the following registry key Hkey_Local_Machine\System\Current_Control-Set\Service\MsexchangeIS\
5. Expand the key and check the Public- and copy that GUID number.

6. Within regedt32 now go to the following registry key HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\Schema

7. Add a DWORD value with same name as the GUID of the public store above enclosed in curly brackets {} and set the value to 0

8. Restart the information store service.

9. Check that the registry value for the public folder schema object is now updated to 2 from 0.

10. Next go back to ADSIedit and change the msExchFirstInstance value on that public Folder object to not set again. Note if there is no other server with this attribute set you may want to leave it set to true.

11. The schema folder should be recreated for the organization



Hope this helps

[Barbara_Gargone]

We are experiencing the same OWA problem you described last year. The @65K attachment issue, and the missing schema-root folder in AD under MSEO container. The schema folder is visible using ESM.

We are running Exchange 2003 SP2, with Enterprise Vault 6.0 SP4 (just installed the DST upgrade, however, we had this issue with SP2 which was never addressed.)

Before I attempt the fix you posted, I have a few questions that I'm hoping you can answer for me.

1. The fix mentions deleting the schema-root folder from ESM. Do you know of any effects this may have on existing public folders? Can this be safely deleted?

2. We have 9 backend Exchange servers. Does this fix have to be applied to each Exchange server, or can I apply it to the first Exchange server installed in the Organization and it be recreated in AD for the other servers to see? Since it requires a restart of the IS, I'm hoping to only have to apply it one time.

Thanks for any advice you can offer.