Is it possible to find the owner of a shared mailbox hosted in Office 365 with PowerShell as a non-admin user? I am able to find this information manually through Outlook, but that is not a feasible approach for a large number of shared mailboxes. So I thought that it must be some way to get this information through PowerShell.
It seems that Microsoft offers a lot of PowerShell cmdlets that you can run on the Exchange server itself, but I don't have admin access to it, and I don't want it either. So is this possible to solve as a normal user?
Related
I have a hybrid environment with on-prem exchange (almost done migrating) and O365 Email.
I create a new user in our on-prem AD via powershell. It syncs properly via AADConnect to our Azure environment and creates the O365 user and Exchange online (O365) email account. Using powershell I can correct proxy addresses and the msExchRecipient/Remote attributes.
The expected result is that I have an email account on both sides for the hybrid environment, with the on-prem Exchange srerver showing the Mailbox Type as "Office 365".
For one particular user, I ended up with email accounts in both on-prem and online exchange as expected. The user receives messages in their O365 account. However, messages that are trapped by our Mimecast server are not getting through. The Mailbox Type listed in on-prem is "User". This is messing up the mail routing for incoming messages from outside the domain.
Is there a way I can powershell my way out of this mess and somehow convert the mailbox type from "User" to "Office 365"? I can't migrate the user because the account already exists in O365. If I delete the O365 I would lose the email.
Should I have my powershell user creation script create the ad user, create the on-prem mailbox and also perform the migration? At least until we are fully migrated and out of our hybrid environment?
For this user, would it work to delete the AD and on-prem Exchange, and re-create both manually? How would I connect the on-prem to online exchange without losing the mail?
Any insight into this can of worms would be greatly appreciated.
One of the documents I referenced is this one about Recipient Type Values:
https://answers.microsoft.com/en-us/msoffice/forum/all/recipient-type-values/7c2620e5-9870-48ba-b5c2...
: Keith
I need to get a list of all mailboxes.
Can I get this list with EWS and PowerShell?
Exchange online shell will not be installed on the server where I run the script.
Thanks for your support
With PowerShell you can just simple call the Get-MailBox powershell command.
This is working for on-premise and O365 mailboxes as well. For O365 environment sooner or later you will need to transfer to modern authentication, but basic authentication will still work for a while. This is the easier way of I can think of.
Based on my knowledge it's not possible to list all mailboxes using entirely with EWS.
I am currently using O365 Graph API to create services for customers and realized that some of the capabilities that customers need, i.e. creating transport rules or accessing quarantined email information, are only available through PowerShell.
Can a vendor create transport rules or execute PowerShell commands for their customers? Similar to how vendors register their Azure AD application and request permissions, is there a way to run PowerShell command for customers by a vendor?
Documentation is not really helpful on this front.
When using Graph, I don't think you can, but if you want to do it with Powershell, if you're a Microsoft Partner, and have configured yourself as an advisor (delegated access permissions) for your clients (invite them to add you, or add yourself if you have their consent and global admin access to their tenancy).
Adding a partner to a tenant:
https://learn.microsoft.com/en-us/partner-center/customers_revoke_admin_privileges
See a bit of additional info here:
https://learn.microsoft.com/en-us/office365/enterprise/powershell/manage-office-365-tenants-with-windows-powershell-for-delegated-access-permissio
When running Powershell commands, you'll need to refer to the TenantID when running a command on the client's tenancy (rather than your own).
A simple example of this might be:
Get a list of TenantIDs:
Get-MsolPartnerContract -All | Select-Object TenantId
Get a list of mailboxes for one of the TenantIds listed above:
Get-Mailbox -TenantID "asddfsdfadfg-dsfgsdfg-sdfgsdfg-dsfgsdfg"
This relies on you having logged into the Powershell session with a user that has administrative 'Partner' permissions in your partner tenancy.
Hopefully that helps somewhat!
The helpdesk will be using a script I wrote to set out of office replies and to modify folder permissions but are running into permission issues using them. Is there any resource that would indicate what permissions each powershell command in the exchange cmdlet takes to be able to be ran? Failing that does anyone know the specific permissions needed to set OoO and modify folder permissions?
I did find this that gives specific roles needed to do various things but it's not quite what I'm looking for. These roles give access to far more than what we need.
EDIT: The Auto Reply role is all that is required to set allow use of the Set-MailboxAutoReplyConfiguration. Looking into the others still.
That seems to be as granular as the roles get.
If you want to restrict them further, you can set up one or more remote sessions they can connect to that use a delegated account that is an Exchange role member, and constrain the session to just being able to run your script.
Does any one know a way to give userA full access to userB's mailbox with the exception of one folder in the userB's mailbox using PowerShell.
Thanks in advance
You cannot use the Add-MailboxPermission cmdlet to give full access to a mailbox and then restrict access to one mailbox folder. The Add-MailboxFolderPermission is available in Exchange 2010 and up. You could try using Exchange Web Services (EWS). Read this blog, there might be code from that script you can use.
http://gsexdev.blogspot.com/2008/10/exchange-reverse-permission-audit.html#!/2008/10/exchange-reverse-permission-audit.html