We have a hybrid exchange environment that has all it mailboxes online. ExternalDirectoryObjectId is present in the results for EXO or Azure Powershell user management tools.
However, when i run Onprem Exchange PowerShell tools such as get-remotemailbox against users, the ExternalDirectoryObjectId property is listed but blank.
I have synced msDS-ExternalDirectoryObjectId back from Azure and this populates ExternalDirectoryObjectId for local AD get-aduser commands but not OnPrem Exchange tools.
I think i need to populate the AD user property msexchExternalDirectoryObjectId but i am unsure exactly how to set this up in in AD connect or what online property to sync with?
Has anyone had this issue before and can offer any advice on how to resolve it?
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'm relatively new to the whole Microsoft environment and this has been tickling my brain for a while. What exactly is the difference between company users present, for example, in the Microsoft 365 admin center and on AzureAD for propery-editting purposes? Are they both synced together, do they serve different purposes? Most powershell scripts I find to retrieve, for example, all users and properties use cmdlets such as Get-AzureADuser, hence the question.
Thank you in advance!
They are the same.
The basic attributes of the users are stored in Azure AD and you can use Microsoft Graph to query them easily.
The difference between them is:
In O365 admin center, you can manage the access to resources under O365 subscriptions. For example: Exchange Online, SharePoint online, Teams Online and so on. But in Azure Portal, you can manage the access to resources under Azure subscription, such as Azure web app, Azure AD app registration, Azure VM, Azure security group and so on.
The company users indeed are Azure AD users. It's just called differently according to the environment (O365 or Azure AD).
Get-AzureADuser is under Azure AD PowerShell Module. You can also use Get-MsolUser which is under MSOnline PowerShell Module (it's old O365 Module) to get the users.
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!
I'm using the PowerShell CmdLets to automate most tasks against Windows Azure Cloud Services and Windows Azure Web Sites.
For Cloud Services, I can use the Get-AzureDeployment CmdLet. However, the similar Get-AzureWebSiteDeployment CmdLet requires Git to be installed before it can run and does not seem to be designed for the same task.
As far as I can see, the Get-AzureWebSite CmdLet only ever retrieves the "Production" slot of a Windows Azure Web Site.
How is it possible to get programmatic access to the corresponding "Staging" slot ?
We are working on some PowerShell cmdlets to support website slots. We are very close to releasing it. Keep an eye on this repo on github. https://github.com/WindowsAzure/azure-sdk-tools
Current date update (Jul 19 2015):
According to Azure Docs Web Sites Staging Slots there are new CMDLets that support querying Slots:
Show-AzureWebsite -Name webappslotstest -Slot staging
And some others cmdlets extended with -Slot attribute (Create New Website, Remove, Switch Slots).