cancel
Showing results for 
Search instead for 
Did you mean: 

65@ sign in the attachment trough OWA

Jay_Rodz
Level 3
Partner
Any body know how to correct the 65@ sign representing an attachment? I have run the cscripts a lot of time and uninstall the extension a few more time. I am planning to uninstall my Exchange server and reinstall everything again. Any idea will be very appreciate.
5 REPLIES 5

Alan_M
Level 6
Are you seeing this in v7 when you use a custom shortcut and choose to have links to the attachments? I've never found a way to correct this you may want to open a ticket with Support.

Jay_Rodz
Level 3
Partner
I am working a ticket 2 months ago with support without solving the issue. :(

TonySterling
Moderator
Moderator
Partner    VIP    Accredited Certified
Jay,
What is the Exchange and EV versions? (including sp's)

W_Wintermute
Level 4
The @65B means that the EV forms have not registered correctly with the system mailbox(es) on the Exchange Server.

If you've been working with support for two months, I'm assuming you've gone through the following KB:

http://support.veritas.com/docs/280615

I would also visually inspect the system mailboxes for each mailbox store:
ESM/Servers/Server Name/Storage Group/Mailbox Store/Mailboxes
(and)
ADUC/View/Advanced Features � Microsoft Exchange System Objects

Is the System Mailbox even there? Is the display name populated? Does the e-mail address look ok?

All of this can affect whether the forms get correctly registered.

Check the backend2003setup.wsf.log file to see which system mailboxes failed to register. What's the error?

Barbara_Gargone
Level 4
There is also another thread on this issue with a resolution from Microsoft. We have the same OWA @65B attachment issue and missing OWA EV toolbar buttons. Running EV 6.0 SP4 with Exchange 2003 SP2.

I'm pasting the thread and recommended resolution at the end of this post.
But I'm hoping to get a few questions answered before I apply the fix.

The issue has to do with the schema-root folder missing from AD within the MS Exchange System Objects folder, but it's visible when viewing "system folders" in ESM.


1. The fix mentions deleting the schema-root folder from ESM and then recreating it in AD. Does anyone know of any effects this may have on existing public folders? Can the schema-root folder within ESM 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.

3. I also found another article regarding missing schema folders, that is, not present under the ipm subtree, setting the following registry key to a REG_DWORD value of 0, causes the schema to be repopulated:

HKLM\System\CurrentControlSet\MSExchangeIS\Parameters\Schema\

Item #3 seems more friendly than the below MS fix. Has anyone dealt with re-creating schema-root folders to fix this issue?

Thanks in advance.

Barb

Discussion Issue: "Exchange 2003 SP2 OWA not showing archived Messages" Posted: Feb 20, 2006. by Dan Littman

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