Powershell – Set O365 Calendar Permissions

Powershell – Set O365 Calendar Permissions

By default, in Exchange and Office 365 organization users can’t view Outlook e-mails or calendar items of other users. The only permission that is provided to all users by default is the ability to view the Free/Busy information in other user’s calendars (this is AvailabilityOnly role). Users can independently grant the necessary permissions for Outlook mailbox folders and items to other users (from the Outlook/OWA interface). Unfortunately, in Exchange 2016/2013 and Exchange Online (Office 365), the administrator cannot centrally manage calendar permissions from the GUI (Exchange MMC, EAC—Exchange Administration Center, or Office 365 admin portal). However, you can use a built-in Add-MailboxFolderPermission cmdlet, which allows managing user permissions on any user’s mailbox folder from PowerShell (this cmdlet first appeared in Exchange Server 2010). This cmdlet is also supported in Office 365. Connecting Office 365/Exchange from PowerShell First, you need to connect to your Office 365 or on-premises Exchange tenant. Run the Windows PowerShell CLI as Administrator; Run the following command to save your administrator’s credentials into the PowerShell variable: LiveCred = Get-Credential If you are trying to connect to Office 365, specify your Office 365 tenant admin credentials: Note. How to connect and manage Office 365 using PowerShell. Now you need to create a new session: For Office 365: $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $LiveCred - Authentication Basic –AllowRedirection For Exchange Server 2010, 2013, 2016, and 2019: $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://<your-target-exchange-server-address>/powershell/ -Credential $LiveCred Note. In our case when we tried to run the previous command to connect Exchange 2010 we’ve received an error: [ny-msg-02] Connecting to remote server failed with the following error message: The WinRM client cannot process the request. The WinRM client tried to use Negotiate authentication mechanism, but the destination computer (ny-msg-02:443) returned an ‘access denied’ error. Change the configuration to allow Negotiate authentication mechanism to be used or specify one of the authentication mechanisms supported by the server. To use Kerberos, specify the local computer name as the remote destination. Also, verify that the client computer and the destination computer are joined to a domain. To use Basic, specify the local computer name as the remote destination, specify Basic authentication and provide user name and password. Possible authentication mechanisms reported by the server. In our environment in order to connect to the target Exchange CAS server, we should use the HTTP connection (instead of HTTPS) and Kerberos authentication. The connection command should look like this: $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://ny-msg-02/powershell/ -Credential $LiveCred -Authentication Kerberos The next step is to import Office 365/Exchange management commands from another session to your PowerShell console: Import-PSSession $Session Tip. It happens that when you run the Import-PSSession command, you can face an error: Import-PSSession: Files cannot be loaded since running scripts has been disabled on this system. Provide a valid certificate with which to sign the files. In this case, you need to allow script executing. Do this by setting the PowerShell Execution Policy value to RemoteSigned: Set-ExecutionPolicy RemoteSigned Hint. If you logged in directly to the on-premises Exchange server, you can either start the Exchange Management Shell right away, or run a regular PowerShell.exe CLI, and load Exchange cmdlets with the command: Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn How to Get Mailbox Calendar Permissions Using PowerShell? You can view current calendar (folder-level) permissions of the specified mailbox by using the ALL cmdlet (this cmdlet is available in the cloud-based service and in on-premises Exchange): Get-MailboxFolderPermission username:\calendar Change the username to the user account you want to check calendar permissions for; Hint. If, when executing the following commands, you’re facing an error: Get-MailboxFolderPermission : The term ‘Get-MailboxFolderPermission’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again this means you did not complete the steps to connect to your Exchange/Office 365 tenant and did not import PowerShell Exchange cmdlets into your session. Carefully read and follow the steps from the previous paragraph.Note. If this command returns that ‘username:\calendar’ cannot be found, most likely the user has Outlook language settings other than English. Appropriately, the Calendar folder name can be different (calendar\kalender\calendario\calendrier\календарь). For example, for the Dutch Language (nl-NL), to view calendar permissions use the command:Get- MailboxFolderPermission username:Agenda You can get the name of the calendar in the current user’s language configuration with the command: Get-MailboxFolderStatistics username -FolderScope Calendar).Identity Check the current calendar permissions with the command: Get-MailboxFolderPermission brett.jackson:\calendar As you can see, the default AvailabilityOnly role is assigned on a calendar folder only. You can get the list of all mailbox calendars permissions in your organization using the following command: Get-Mailbox | ForEach-Object {Get-MailboxFolderPermission $_”:\calendar”} | Where {$_.User -like “Default”} | Select Identity, User, AccessRights Tip. In on-premise Exchange, you can view user’s calendar settings in a specific mailbox database using the following command: Get-Mailbox –database mbxdbname | ForEach-Object {get-MailboxFolderPermission $_”:\calendar”} Change mbxdbname to the name of your Exchange mailbox database. Tip. You can use the Get-EXOMailboxFolderPermission cmdlet instead of Get- MailboxFolderPermission to view the permissions of mailbox items in the Exchange Online PowerShell V2 module. Outlook: Calendar Permission Levels and Access Roles When managing calendar and Outlook folder permissions, you can use the following built-in Exchange roles: Owner — gives full control of the mailbox folder: read, create, modify, and delete all items and folders. Also, this role allows to manage item’s permissions; PublishingEditor — read, create, modify, and delete items/subfolders (all permissions, except the right to change permissions); Editor — read, create, modify, and delete items (can’t create subfolders); PublishingAuthor — create, read all items/subfolders. You can modify and delete only items you create; Author — create and read items. Edit and delete own items; NonEditingAuthor — full read access, and create items. You can delete only your own items; Reviewer — read folder items only; Contributor — create items and folders (can’t read items); AvailabilityOnly — read Free/Busy info from the calendar; LimitedDetails — view availability data with calendar item subject and location; None — no permissions to access folder and files. You can also use granular permissions to fine-tune the access rights to the mailbox calendar. The following values are available: CreateItems; CreateSubfolders; DeleteAllItems; DeleteOwnedItems; EditAllItems; EditOwnedItems; FolderContact; FolderOwner; FolderVisible; ReadItems. The Permission Level roles described above are just a set of granular permissions. For example, the Editor role is a set of the following individual permissions: CreateItems, DeleteAllItems, DeleteOwnedItems, EditAllItems, EditOwnedItems, FolderVisible, ReadItemshttps://51e448f02aa451f6a7e42f2ac1d1f720.safeframe.googlesyndication.com/safeframe/ 1-0-38/html/container.html These permissions can be set using the –AccessRights parameter of the Set- MailboxFolderPermission cmdlet. How to Set Office 365/Exchange Calendar Permissions Using PowerShell? In order to grant user2 the permissions to view and edit user1 calendar items, run the following command: Add-MailboxFolderPermission -Identity [email protected]:\calendar -user [email protected] -AccessRights Editor If some of the items in the calendar are marked as Private, you can allow delegating the permissions to view Private calendar items using the command: Add-MailboxFolderPermission –Identity [email protected]:\calendar –User [email protected] -AccessRights Editor -SharingPermissionFlags Delegate,CanViewPrivateItems If you need to change the Default permissions for the calendar folder (to allow all organization users to view a calendar of the specified user), run the command: Set-MailboxFolderPermission -Identity [email protected]:\calendar -User Default -AccessRights Reviewer Check the current calendar permissions again using the Get-MailboxFolderPermissions cmdlet, they should change: Get-MailboxFolderPermission -Identity [email protected]:\calendar FolderName User AccessRights ———- —- ———— Calendar Default {Reviewer} Calendar Anonymous {None} Calendar user2 {Editor} You can also grant permissions for the mailbox not to an individual user, but the Exchange distribution group: New-DistributionGroup -Type Security -Name “Resource Calendar Owners” -Alias “grResourceCalendarAccess” add-MailboxFolderPermission -Identity [email protected]:\calendar -User grResourceCalendarAccess -AccessRights Owner In

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    8 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us