Blog - Title

May, 2010

Brijs Blogging... Looking Beyond the Obvious

  • Brijs Blogging... Looking Beyond the Obvious

    Where is PFDAVAdmin for the Exchange Server 2010? ExFolders is here now!!!

    • 1 Comments

    Users of PFDAVAdmin on Exchange Server 2003/2007 must be wondering that with the recent release of Exchange Server 2010, PFDAVAdmin is no longer available to work because WebDAV is gone from Exchange 2010.

    However, We can accomplish a lot of the things which we used to do only in PFDAVAdmin, with Exchange PowerShell Cmdlets e.g. Get-PublicFolder and Set-PublicFolder can be used to export and import permissions; and Get-MailboxFolderPermission and Set-MailboxFolderPermission can be used to export and import mailbox permissions. However, there are still a few things we just cannot do without PFDAVAdmin.

    Fortunately, we have a solution - a tool called ExFolders. This new tool is really just a port of PFDAVAdmin to Exchange 2010. For details we can refer to the announcement from Bill Long @ Exchange, meet ExFolders. ExFolders still has the same user interface as PFDAVAdmin, so things will look very familiar. However, there are a few changes to note as mentioned below.

    • ExFolders must be run from an Exchange 2010 server - it cannot be run from a workstation as PFDAVAdmin could.
    • It can connect to Exchange 2010 or Exchange 2007, but not older versions.
    • Permissions export format between PFDAVAdmin and ExFolders are compatible.

    Here is the list of a few new features:

    • Folder property imports are now supported. We were able to do folder property exports with PFDAVAdmin, but not imports.
    • Item property exports are supported i.e. we can export a set of properties from all items in a folder. However, Item property imports are not supported.
    • ExFolders supports the new free/busy permissions that were introduced in Exchange 2007 and Outlook 2007.
    • We can now connect to multiple mailbox stores at the same time, so you can run a batch operation against several mailbox stores or all mailboxes in the organization as well.

    I would also suggest you to go through the readme for more details. I would also like to mention that there is No official support for the ExFolders (as like for PFDAVAdmin).

    We can download ExFolders @ http://msexchangeteam.com/files/12/attachments/entry453398.aspx

    Enjoy!!!

  • Brijs Blogging... Looking Beyond the Obvious

    Getting “Derived types must either match the security accessibility of the base type or be less accessible” exception after migrating VSTO add-in project to Visual Studio 2010 and targeting it to .Net 4.0 Framework.

    • 3 Comments

    We are getting following exception after migrating Outlook 2007 VSTO add-in project to Visual Studio 2010 and targeting it to .Net 4.0 Framework for Outlook 2010:

    Inheritance security rules violated by type: 'VS2008_FR_OLAddIn.ThisAddIn'. Derived types must either match the security accessibility of the base type or be less accessible.

    ************** Exception Text **************

    System.TypeLoadException: Inheritance security rules violated by type: 'VS2008_FR_OLAddIn.ThisAddIn'. Derived types must either match the security accessibility of the base type or be less accessible.

    at System.Reflection.RuntimeAssembly.GetType(RuntimeAssembly assembly, String name, Boolean throwOnError, Boolean ignoreCase, ObjectHandleOnStack type)

    at System.Reflection.RuntimeAssembly.GetType(String name, Boolean throwOnError, Boolean ignoreCase)

    at Microsoft.VisualStudio.Tools.Office.Runtime.DomainCreator.ExecuteCustomization.CreateEntryPoint(String entryPointTypeName)

    at Microsoft.VisualStudio.Tools.Office.Runtime.DomainCreator.ExecuteCustomization.Microsoft.VisualStudio.Tools.Office.Runtime.Interop.IExecuteCustomization2.LoadEntryPoints(IntPtr serviceProvider)

     

    The above issue is happening in case if we upgrade an Office project from Visual Studio 2008. In this case, you must remove the SecurityTransparentAttribute.

    Visual Studio does not automatically remove these attributes when the target framework is changed.

    StepsTo remove the SecurityTransparentAttribute

    • With the project open in Visual Studio, open Solution Explorer.
    • Under the Properties node (for C#) or the My Project node (for Visual Basic), double-click the AssemblyInfo code file to open it in the code editor.
    • Locate the SecurityTransparentAttribute and either remove it from the file or comment it out.

    For more detail refer @ Removing Obsolete Attributes from Office Projects that You Migrate to the .NET Framework 4.

     

    We would also need to keep in consideration Required Changes to Run Office Projects that You Migrate to the .NET Framework 4 to avoid other issue.

    Hope this helps!!!

Page 1 of 1 (2 items)