Background:
It seems someone has set user-mailbox permissions using the O365 GUI (not exchange online GUI):
Issue:
This means I can't use the normal exchange-powershell method to check mailbox permissions... like we can if set using Exchange Online Admin Center GUI or Add-MailboxPermission:
Import-PSSession ( New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Authentication Basic -AllowRedirection -Credential (Get-Credential myname#myco.com ) )
Get-MailboxPermission SharedUser#myco.com
^^ This does not return the permissions set in O365 GUI. Only Exchange Online.
Question:
What is the correct commandlet to manage the permissions set using the O365 GUI ?
Previous work:
I have tried looking at the MSOL-User commandlets also, as these seem to use O365 rather than exchange online... but they don't have one relating to permissions.
Also I have previously checked mailboxfolderpermission.
More Clarifications:
StaffMember#myco.com can see SharedUser#myco.com's mailbox in outlook.
This is also represented in:
Office 365 control panel / GUI > Users > SharedUser > Mail Settings > Mailbox Permissions
These permissions do NOT seem to show in Exchange Admin Center or exchange powershell.
There are three types of permissions you can set over the mailbox: FullAccess, SendAs and SendOnBehalf. Each of them can be checked/managed using different cmdlets:
FullAccess (Read and manage in O365 GUI) can be viewed using Get-MailboxPermission and managed using Add-MailboxPermission/Remove-MailboxPermission
SendAs can be viewed using Get-RecipientPermission and managed using Add-RecipientPermission/Remove-RecipientPermission
SendOnBehalf can be viewed using Get-Mailbox and managed usingSet-Mailbox (parameter GrantSendOnBehalfTo)
Clarifying the question from comments:
Unfortunately Get-RecipientPermission says "applied to: Exchange online" and I am specifically talking about Office365 which seems to be a different set of cmdlets. Other-User had full access to shared-user's mailbox, yet Get-MailboxPermission shared-user showed nothing about the Other-User.
The fact that permissions can be set via O365 portal doesn't mean that the permissions are not set in Exchange Online. Office 365 user objects (the ones you can access via Get-MsolUser) cannot have FullAccess/SendAs/SendOnBehalf set on them, only mailboxes can have them.
When you set the permission (let's say you add Read and manage over shared-user to other-user) via O365 portal, the change should reflect on the Exchange Admin Center (when you check shared-user you'll see other-user in Full Access field) and in Get-MailboxPermission shared-user. Not sure what happened that you haven't seen these permissions but check these three first. It might be some delay in synchronization too.
Related
I want to be able to set an email forward in Exchange Powershell O365
I'm trying
Set-Mailbox -Identity emailaddress -DeliverToMailboxAndForward $true -ForwardingSMTPAddress forwardingaddress
but getting
A parameter cannot be found that matches parameter name
'DeliverToMailboxAndForward'.
Do I need to load a snap-in? I can't find any help about this.
You forgot your $'s my friend
Set-Mailbox -Identity $emailaddress -DeliverToMailboxAndForward $true -ForwardingSMTPAddress $forwardingaddress
Also something to look out for when using Exchange Online PSSession (and maybe regular Exchange PSSession) is that it uses the JEA functionality of PowerShell. JEA is Just Enough Administration it actually looks at what roles the account used to connect to the PowerShell Session has and it ONLY gives you the commands that account has the roles to do. I'm not sure if it goes to the level of removing parameters from functions you only have partial access to do. For the missing Cmdlet part though I ran into this while beating my head against the wall writing a batch migration utility come to find out SysAdmin never gave me the permission to do batch migration. As soon as They gave me the permission and I imported the PSSession again BAM Cmdlet was there.
Hope that helps.
Background
Working in a small O365 environment that recently upgraded from E3 to E5.
Issue
The audit log shows that a user enabled DeliverToMailboxAndForward on their mailbox with the Set-Mailbox operation.
Questions
Is PowerShell the only way to issue Set-Mailbox or can it be done
through the GUI somehow?
Is there a way to disable/prevent users from settings this (i.e. do the end users have too many permissions)?
When I query Get-Mailbox user | fl name,forwardingSMTPAddress,delivertomailboxandforward the ForwardingSmtpAddress is empty and DeliverToMailboxAndForward is False. Is this the only way to ensure the action is disabled? Does the disable action appear in any event/audit log?
Is PowerShell the only way to issue Set-Mailbox or can it be done through the GUI somehow?
As an Exchange admin, you can use the Exchange Admin Center (EAC) to go to the Mailbox properties -> Mailbox Features -> Under Mail Flow, select View details -> Check the Enable forwarding, and Browse to the recipient.
Configure email forwarding for a mailbox
Is there a way to disable/prevent users from settings this (i.e. do
the end users have too many permissions)?
From a user perspective they can forward using the Outlook GUI:
Forward email from Office 365 to another email account
When I query Get-Mailbox user | fl name,forwardingSMTPAddress,delivertomailboxandforward the
ForwardingSmtpAddress is empty and DeliverToMailboxAndForward is
False. Is this the only way to ensure the action is disabled? Does the
disable action appear in any event/audit log?
You can use either the PowerShell script to query, or navigate through ECA console to verify. The disable action should appear in the audit if it is set up.
On to the issue,
The audit log shows that a user enabled DeliverToMailboxAndForward on
their mailbox with the Set-Mailbox operation.
Typically most users don't have access to the Exchange Management Console, and the ability to run PowerShell operations. That makes this audit entry "seem" odd. But then digging through the docs I come up to this entry:
Cmdlets that are run directly in the Exchange Management Shell are
audited. In addition, operations performed using the Exchange admin
center (EAC) are also logged because those operations run cmdlets in
the background.
Administrator audit logging in Exchange Server
So what you are likely seeing is an entry that is a GUI running a cmdlet in the background, without the user actually having direct Exchange Management Shell access. As for permissions, I'm not sure about explicit permissions to deny this specific action without denying a lot of other stuff (i.e. it's like denying permissions to forward messages) unless you have a business need to do this.
This question may get a better response in an Office 365 forum, but I'll try to answer your questions:
The GUI/Web UI is executing PowerShell commands on the back end when users change their configuration. In order to be allowed to change a setting in the GUI, the same permission needs to exist for the PowerShell cmdlets.
This permissions is a default included in the MyBaseOptions management role for Office 365 mailbox users. This role includes many other permissions which users require to manage their own mailbox, such as permissions to create inbox rules or update their picture. You can see all the actions included in this role with this command:
Get-ManagementRole -Identity mybaseoptions |Select -Expand roleEntries
The easiest way to audit current mailbox settings is likely running the command as you have done. A more efficient way to query all your mailboxes for just those with specific settings is to use the -Filter parameter on the Get-Mailbox command like this:
Get-Mailbox -Filter {DeliverToMailboxAndForward -eq $true -and ForwardingSMTPAddress -ne $null}
I hope that helps answer your questions!
I am working on proofing out if there is a way to automate a Global administrator's Azure AD access for other User role accounts in the same tenant to grant access to OneDrive.
If you navigate to portal.office.com and then click on a user's name, that will bring up some settings for that user. The setting I am referring to is under the dropdown for OneDrive Settings, (see attached image).
Is there a way to automate this process via some PowerShell cmdlet?
Solved
I found an article that shows how to run PowerShell commands via the SharePoint Online Management Shell
Tutorial link has the section for Prerequisites for setup: Easy Manage Multiple Office 365 Tenants with Windows PowerShell
Actual PowerShell commands:
$site = Get-SPOSite -Identity https://mydemo-my.sharepoint.com/personal/sarad_mydemo_onmicrosoft_com
Set-SPOUser -Site $site.Url -LoginName admin#mydemo.onmicrosoft.com -IsSiteCollectionAdmin $true
Tutorial: How to Get Administrative Access to the OneDrive for Business Environment for a User
I would like A PowerShell script to automatically connect to office 365 and to run as a scheduled task twice a day, THEN assign Reviewer permissions to new users if not possible then reviewer for all users. the reason being is because when a new user is created in outlook 365 their calendar permissions are set to free/busy.
i suggest you take a look at: OfficeDev/PnP - TimerJob
Shows how to create "remote timer job", which could be installed to be running as a WebJob to Windows Azure or scheduled to windows scheduler for on-premises deployment.
This is entirely possible, with the obvious downside that you'll need to store credentials for an account with permissions to edit all user calendars by default to run the script with.
There are two parts to the script that you'll require:
Connecting to Exchange Online
As shown here, connecting to Exchange Online is a very simple process.
Leaving the question of how to store credentials in a secure method out of scope of this question, this will result in a PowerShell session to the Exchange servers:
$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session
Selecting New Users
You'll then need to either select the new users (by passing them to this script, or scanning AD - this will depend on how you're creating your users - synced from AD or just created in-cloud), and apply the permission change to them. However...
Changing Default Permissions on Calendars
In this case, as I don't know how you're creating the new users, or how best to test that, I'm simply applying it to everyone. This will take far longer in a large environment, and is just a pretty bad idea.
Get-Mailbox -Filter {RecipientType -eq 'UserMailbox' -and IsShared -eq $false}| %{
Set-MailboxFolderPermissions -Identity "$($_.Alias):\Calendar" -User Default -AccessRights Reviewer
}
Finally, according to the original article, you should close the remote session.
Remove-PSSession $Session
Scheduled Tasks
After fixing the issue with credentials, you'll then want to save the script (ensuring that it complies with the Execution Policy on the system you'll be running it on), and create a new scheduled task to run it.
Configure a Scheduled Task as appropriate (in terms of triggers and conditions), and set the Action as Start a program, with that program being powershell.exe. Arguments should include -File C:\Path\to\Saved\Script.ps1 and any arguments (such as a file of new users).
Having said all of that, what you should actually do is change the sharing policy in 365, which will allow you to set the default permission for calendars.
i often use the New-MailboxExportRequest 's command on an exchange server in powershell console, like this one :
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010;
New-MailboxExportRequest -Mailbox jadrego –filepath \\computer1\c$\test.pst -verbose
it works correctly. But if I run those commands in PS remote session like this one :
I use the same User (Domain Admin, Exchange Admin)
Invoke-Command -ComputerName vdiv03 -ScriptBlock {
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010;
New-MailboxExportRequest -Mailbox jadrego –filepath \\computer1\c$\test.pst
}
I obtain this error :
failed to comunicate with mailbox database
with -verbose
Loading the snapin like that isn't supported in Exchange 2010.
IMHO, you'd be much better off just leveraging the native remoting built into Exchange for management tasks.
$ExchangeServer = <exchange serer name>
$SessionParams =
#{
ConfigurationName = 'Microsoft.Exchange'
ConnectionURI = "http://$ExchangeServer/powershell/"
Authentication = 'Kerberos'
# Credential = $Creds
}
$Session = New-PSSession #SessionParams
Invoke-command -ScriptBlock {New-MailboxExportRequest -Mailbox jadrego –filepath \\computer1\c$\test.pst} -Session $Session
Remove-PSSession $Session
Set $ExchangeServer to the name of one of your Exchange 2010 servers. The account will need to be a member of the necessary RBAC role for the function you're performing, and you can uncomment the Credential parameter and provide alternate credentials for the session if you need to.
This will also elimnatat the need to have the management tools installed on the computer that's running the script, and the associated headaches of keeping it patched to the same level as what's on the servers.
If you're working interactively, or running a script that uses many Exchange cmdlets you can add the session creation to your profile, and do an Import-PSSession and you'll have proxy functions for the Exchange cmdlets available locally that you can use the same as if you'd loaded the snapin.
Import-PSSsession $Session
Some caveates to be aware of:
When you use implicit remoting like this, the account of the credentiaals used to establish the session will determine what capablilities you will have. What appear to be Exchange cmdlets added to the local session are actually proxy functions ( you can verify this using Get-Command). This set of proxy functions is created dynamically by Exchange when you initially establish the session and will be customized according to the RBAC roles the account making the connection belongs to. If it doesn't have permissions to perform given functions you will not get the proxy functions for those cmdlets, or functions may not have parameters for those functions.
The results you get back will not be the same as the same as the native objects returned if you used an EMS shell, or loaded the snapin. They will be deserialized objects, which means they may be missing methods and will lose some fidelity compared to the native objects. There will be very few instances where this will be an issue, or cannot by worked around.
Also be aware that when you use implicit remoting, updates are made under the authority of an Exchange system account, not your credentials. When you use the snapin, your account must have permission to update the Exchange properties stored in AD directly, and those changes will be logged in Windows audit logs (if enabled) as having been made by that account. When you use implicit remoting they will be recorded as being done by the Exchange service account. Exchange will record the details of the actual user account that made the request in it's admin audit log, and you can use Search-AdminAuditLog to find out when changes were made, and by who even if Windows audit logging is not enabled. If you use the snapin directly and do not have AD audit logging enabled you will lose that audit trail.