Search blog.co.uk

  • Enterprise Vault Product Management Team Blog

    There's a new Enterprise Vault Blog that's worth a visit.

    The EV Product Management Team have now started posting to the following URL, it's a useful source of additional information about service packs, fixes and features.

    https://forums.symantec.com/blog?blog.id=EV_team_blog

  • ExchangePerfLog files created in Temp Directory

    Just thought it would be useful to post this one, it's something I first saw last year and escalated throught EV support and also to Microsoft. This only applies if you're using OL2003 on the EV server

    If you check the temp directory on your EV server you may well find 1000's of these exchangeperflog files. You'll need to check the temp folder for the account that runs the EV services (normally in C:/documents and settings/...../local settings/temp) unless you've changed it. I wouldn't say there's major impact but it may have a knock on performance effect because you could end up with 10,000's of these files - it's just not good house keeping and is plain annoying.

    These files contain performance information which is useful for troubleshooting OL2003 on a normal client. They're generated because when a temp MAPI profile is created (as with EV) the associated MAPI DLLs will create a perflog file. Normally OL cleans them up when it exits but I'm affraid that EV doesn't do the same so they are just left.

    I've attached the Microsoft response at the end of this post but their recomended action doesn't help and the response from Veritas (at the time) was that they're working on it. I still think it's there cause we still have them and it can run into 1000's per day. Deleting them is the only option which you can do with a nice little script schedule to run each day.

    The MS response follows

    ACTION:
    Running KVS archiving with Outlook 2003 to create temporarily Mapi Profiles

    RESULT:
    ExchangePerfLog*.dat files are created and not cleaned op in the Temp folder

    CAUSE:
    The ExchangePerfLog*.dat files are created and used by Outlook 2003 for sending RPC performance data to Exchange. There is one file for each profile + security context. Perf records that are to be sent to the server are staged in and out of this file so that we minimize the amount of data that we keep in memory at any given time.

    Basically what happens when you use Enterprise Vault from KVS (Veritas) and the Temp Mapi profile is deleted leaves an orphaned ExchangePerflog_*.dat behind, which is not used anymore as its associated Mapi profile does not exists anymore. (KVS removes the Created Mapi profile when it is ready with archiving with the user's mailbox.

    RESOLUTION:
    Installing the Exchange System Manager not only puts on the necessary MAPI files, but also installs CDO. So only installing the Exchange System Manager of Exchange 2003 should be enough for KVS. You might want to install Exchange service packs and the latest CDO update in order to get the most recent files.

  • Version 6 SP1 Documentation

    I'm now looking into V6 so thought it would be useful to collect all the updated documents - here's the online locations for your convenience.

    Changes in V6 SP1 http://support.veritas.com/docs/279962

    Features & Changes in V6 & V6 SP1 http://support.veritas.com/docs/278007

    Introduction and Planning guide http://support.veritas.com/docs/279956

    Installing and Configuring guide http://support.veritas.com/docs/279957

    Administrator's Guide http://support.veritas.com/docs/279959

    Application Programmer's Guide http://support.veritas.com/docs/279960

    Custom Properties & Filters guide http://support.veritas.com/docs/279964

  • Disabling PSTs

    I was trying to figure out how to disable PST creation in OL2003 the other day, surely there's a way I thought. This lead me to an article by Sue Mosher (Nov 20030 on the WindowsitPro site. Hopefully they don't object to me re-printing it here because it's a fantastic reference, so I've included a link to the original article & the artivle text for posterity.

    http://www.windowsitpro.com/Articles/Index.cfm?articleID=40961&DisplayTab=Article

    Re-printed text from the original article

    Microsoft Office Outlook 2003 can support much larger Personal Folders (.pst) files than earlier versions--up to 33TB. Given the possibility that archive or export .pst files might grow large enough to crowd out other data on users' hard disks, you might want to look again at .pst file usage in your organization. Outlook 2003 lets you use Group Policy to control the size of both the old and new .pst files. Even if you aren't planning to move to Outlook 2003 any time soon, knowing how Outlook uses .pst files and which uses you can disable in earlier versions can come in handy.

    Outlook uses .pst files in more ways than you might realize. The most familiar use is a standalone user using a .pst file instead of an Exchange mailbox as the default information store. Users typically can create additional .pst files by turning on Outlook's AutoArchive feature, which moves older items into a .pst file on a regular schedule, or by using the File, Import and Export command to export data to a .pst file. Outlook also automatically creates a .pst file if the user adds an IMAP4 or Hotmail account to his or her email profile; Outlook uses this .pst file to store a local cache of the IMAP or Hotmail account's messages. Finally, Outlook 2003 creates a new .pst file if the user views a Windows SharePoint Services (WSS) events or contacts list and clicks the "Link to Outlook" link; this .pst file contains the local copy of the linked SharePoint lists.

    To provide some control over .pst file use, Outlook 98 and later support a DisablePST registry value. This DWORD value is under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\11.0\Outlook registry subkey in Outlook 2003; change "11.0" to "10.0" for Outlook 2002, "9.0" for Outlook 2000, or "8.0" for Outlook 98. The DisablePST value isn't present by default, so you need to add it if you want to disable .pst file use. Allowable values are 1 (disabled) and 0 (enabled, the default).

    DisablePST's initial use in early builds of Outlook 2002, Outlook 2000, and Outlook 98 was to prevent users from archiving and exporting to or importing from a .pst file. Setting DisablePST to 1 in those versions turns off those features and disables the creation of new .pst files from the File, New menu. User accounts that you configure in Corporate/Workgroup mode, however, can still add a new or existing .pst file to their email profile (through the File, Data File Management dialog box in Outlook 2002 or the Tools, Services dialog box in Outlook 2000 or Outlook 98), so some ad hoc .pst file use is still possible in these versions.

    Beginning with Outlook 2002 (with Office XP Service Pack 2--SP2--applied) and continuing with Outlook 2003, DisablePST blocks all user-controlled methods of creating a new .pst file. Setting DisablePST to 1 prevents all new .pst files except those that Outlook itself creates for use with IMAP or Hotmail accounts or WSS lists.

    Even with the archive and export features disabled, however, users can open an existing .pst file by using the File, Open, Outlook Data File command, and users can copy or move items into that file. If you want to prevent users from opening a .pst file, you can use Group Policy to disable the Outlook Data File command. You'll need to know the command's ID, which is 5576, and be familiar with Group Policy operations. (For Group Policy resources, search the Windows & .NET Magazine Web site at http://www.winnetmag.com .)

    When you deploy Outlook 2003, you can use the Custom Installation Wizard or Custom Maintenance Wizard from the Office Resource Kit (ORK) to determine what kind of .pst files users can create. On the wizards' Change Office User Settings page, look for the PST Settings options under Microsoft Office Outlook 2003/Miscellaneous. You can set values for "Default location for .pst files" and "Preferred PST Mode (Unicode/ANSI)." A Unicode .pst file is the new type supported in Outlook 2003; ANSI refers to the older type that's limited to 2GB. Setting the Preferred PST Mode adds a string registry value named NewPSTFormat to the HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook subkey. NewPSTFormat can have the following values:

    Prefer Unicode PST: 0 (default)
    Prefer ANSI PST: 1
    Enforce Unicode PST: 2
    Enforce ANSI PST: 3

    By using a value of 2 or 3, you can restrict all new .pst files to either the old format or the new format.

    The corresponding set of policies listed in Group Policy Editor (GPE) under User Configuration\Administrative Templates\Microsoft Office Outlook 2003\Miscellaneous\PST Settings goes one step further than the ORK tools and provides a way to limit the growth of both old and new .pst files without totally restricting their use. A bit inconsistently, the policies use the term "Large PST" for the Unicode format and "Legacy PST" for the older ANSI format, but for each .pst format, you can set an absolute maximum size and a separate "Size to disable adding new content." The default maximum size for a Unicode .pst file is about 20GB.

    With this array of policies and registry settings, Outlook--particularly Outlook 2003--lets you control end users' access to .pst files, set .pst file size limits, control the type of .pst files Outlook 2003 users can create, prohibit the use of new .pst files, and even suppress the menu command for opening an existing .pst file.

  • Index Problems - Light at the end of the tunnel

    Well, after nearly two months without incident, the dreaded index corruption occured last week. I dutifully deleted the said index and rebuilt it. Then re-opened my call with Symantec....well actually had to get a new call logged. The discussion clearly wasn't going to go to far so I asked that if it can't be fixed then at least could they commit to fixing the logic to stop flooding the loop of events which eventually flood the eventlog and then cause the admin service to shutdown the EV application.

    Well....I've just heard from the support guys that they will fix this in EV6 SP1 and when an index becomes corrupt they will update the vault database to indicate that the index is corrupt. Then it's just a question of looking out for the appropriate message that gets logged in the event log. We'll have to wait to see if it really works but we're stuck on V5 SP5 and I don't suppose a hotfix will be made available so until we upgrade to V6 I'll keep my fingers crossed we only get one corruption every two months:D

Footer:

The content of this website belongs to a private person, blog.co.uk is not responsible for the content of this website.