In Exchange 2013 you can use Exchange Web Services (EWS)
to accomplish something similar as Managed Folders approach, being able to
create a folder in the user’s mailbox and configure a retention setting for
that folder, with some caveats. You can write your own code or even a
PowerShell script to create a folder in the user’s mailbox and apply a Personal
Tag to it. There are scripts available on the interwebs, including some code
samples on MSDN to accomplish this.
Latest updates on Microsoft Office 2019:
https://www.inteligence.net/question/how-to-create-a-chart-on-access-in-microsoft-office-2019/
Exchange Web Services (EWS) is a supported and
documented API, which allows ISVs and customers to create custom
solutions for Exchange.
If using EWS to apply a Personal Tag to custom
folders helps you meet your business requirements, absolutely! However, do note
and consider the following:
- You’re replicating some of the functionality available via Managed Folders, but it doesn’t turn the folder into a Managed Folder.
- Remember - it’s a Personal Tag! Users can remove the tag from the folder using Outlook or Outlook Web App.
- If you have additional Personal Tags available in your environment, users can change the tag on the custom folder.
- Users can tag individual items with a different Personal Tag. There is no way to enforce inheritance of retention tag if Personal Tags have been provisioned and available to the user.
- Users can rename or delete custom folders. Unlike Managed Folders, which are protected from changes or deletion by users, custom folders created by users or by admin are just like any other (non-default) folder in the mailbox.
When using EWS in your code or PowerShell script
to apply a Personal Tag to a folder, it’s important to consider the following:
For Developers:
- EWS is meant for developers who can write custom code or scripts to extend Exchange’s functionality. As a developer, you must have a good understanding of the functionality available via the API and what you can do with it using your code/script.
- Support for EWS API is offered through our Exchange Developer Support channels.
For IT Pros:
- If you’re an IT Pro writing your own code or scripts, you’re a developer too! Above applies to you.
- If you’re an IT Pro using 3rd-party code or scripts, including the code samples & scripts available on MSDN, TechNet or elsewhere on the interwebs, we recommend that you follow the general best practices for using such code or scripts, including (but not limited to)the following:
- Do not use code/scripts from untrusted sources in a production environment.
- Understand what the script or code does. (This is easy for scripts – you can look at the source in a text editor.)
- Test the script or code thoroughly in a non-production environment, including all command-line options/parameters available in it, before installing or executing it in your production environment.
- Although it’s easy to change the PowerShell execution policy on your servers to allow unsigned scripts to execute, it’s recommended to allow only signed scripts in production environments. You can easily sign a script if it's unsigned, before running it in a production environment.
Latest updates on Microsoft Office 2019:
https://www.inteligence.net/question/how-to-create-a-chart-on-access-in-microsoft-office-2019/
