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
Related
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?
I'm trying to connect Azure DevOps to Azure Active Directory (which is being synced to an on premise AD server) and I keep getting the following error:
Connection Failed Your organization #### failed to connect to the ####
Azure Active Directory.
User: ##AADGUID##\##USER#####DOMAIN## of 1 total users has multiple
active identities with the same UPN. Please either remove the
duplicates or change the UPNs to be unique.
I've looked at the user's account and don't see anything obviously misconfigured compared to any other user's account but that might not be saying much. Any help would be greatly appreciated.
Turns out when our Azure DevOps instance was first set up, all our users set up Microsoft accounts with their company emails. Later when we finally stood up Azure AD but before we connected it to DevOps we added a new project and set the permissions for a few existing employees. For some reason the user permissions on the new DevOps project were listed as "aaduser" type instead of the standard "user" type (ms account) that all the users in other projects in DevOps had. In other words duplicate UPNs but different accounts (but sort of the same). What's weird is that DevOps managed to find the Azure AD user account before we even connected the two together services together.
We removed the offending users with the standard "user" type and re-added them so they were now all listed as "aaduser." We were then able to connect Azure AD. To be clear, this was all done on the DevOps side and had nothing to do with AD.
Not sure why it was finding Azure AD users when we weren't even connected to it yet.
It sounds like you have multiple users in your azure ad tenant with the same UPN.
maybe you created a cloud account with the same UPN before sync'ing the on premise with azure ad connect? or something else of that nature.
try to go to graph explorer https://developer.microsoft.com/en-us/graph/graph-explorer
log in with a azure ad admin account
and type in a query like this
https://graph.microsoft.com/v1.0/users?$filter=startswith(UserPrincipalName,'##UPNHavingIssues##')
That should get you users with a UPN of whatever it having problems. There should only be entry, but if there are multiple, then that's where the problem is.
The other option is to remove the user having issues from devops completely, then try to connect, then re-add him. because when you try to connect devops to an azure ad domain it will try to match the UPNs of users in your devops with users in your tenant.
According to this doc:
During the connect process, we map existing users to members of the Azure AD tenant, based on their UPN, which is often known as sign-in address. If we detect multiple users with the same UPN, we don't know how to map these users.
The cause of this issue is that the target user has the same UPN as other user. A UPN must be unique among all security principal objects within a directory forest.
The UPN contains UPN prefix (the user account name) and a UPN suffix (a DNS domain name).
For example:someone#example.com
You can compare the target account with other user accounts. Then you could find the duplicate UPN.
You could try to remove the duplicate one or change the UPN as unique.
Hope this helps.
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 need to test the pass through authentication connection of a new website using PowerShell.
The code that I have just creates the website.
New-WebApplication -Name DLTItemAnalysis -Site 'Default Web Site' -PhysicalPath C:\inetpub\wwwroot\ApplicationFolder\ApplicationFolder -ApplicationPool ApplicationPool
Set-WebConfiguration "/system.applicationHost/sites/site[#name='Default Web Site' and #id='1']/application[#path='/Application']/VirtualDirectory[#path='/']" -Value #{userName=$ServUserName ;password= $ServUserPassword}
Is there a way to also test the user connection like the GUI has?
I am not really sure what you are asking for here. for as documented:
It is an authentication bridge and a new powerful way of cloud authentication while still keeping your passwords on-premise. It securely validates user passwords with on-premise Active Directory without the need of extra on-premise infrastructure like ADFS. Azure Active Directory (Azure AD) Pass-through Authentication allows your users to sign in to both on-premises and cloud-based applications using the same passwords. This feature provides your users with a better experience - one less password to remember and reduces IT helpdesk costs because your users are less likely to forget how to sign in. When users sign in using Azure AD, this feature validates users' passwords directly against your on-premises Active Directory.
When a user types in his user name and password on office 365 portal https://portal.office.com, office 365 service encrypt this using public key and puts it in a queue for validation, one of lightweight agent makes an outbound call from your network to retrieve the user name and password and decrypts the password using organization’s private key and validate it against local AD. Local AD sends back the resulting success or failure and it goes back to Azure portal via an agent and the user is authenticated.
So, this is nothing more than a standard Windows Kerberos auth request being redirected. So, you are only require testing for normal Windows auth.
As noted above, PTA is a communications channel, not an auth type, like basic, integrated, Kerberos, Kerberos(required), etc. For a target to validate a specific auth type, the target has to be configured for it. There is not PTA auth type as noted above that you can configure on a target.
Microsoft's PTA Video
User sign-in with Azure Active Directory Pass-through Authentication
What is Azure Active Directory Pass-through Authentication? Azure
Active Directory (Azure AD) Pass-through Authentication allows your
users to sign in to both on-premises and cloud-based applications
using the same passwords. This feature provides your users a better
experience - one less password to remember, and reduces IT helpdesk
costs because your users are less likely to forget how to sign in.
When users sign in using Azure AD, this feature validates users'
passwords directly against your on-premises Active Directory
My company is currently migrating our on prem Exchange users to the hosted Exchange Online platform. Migrating users is easy but we have hit a snag when on boarding new users. Our environment has multiple RDS servers. In the past we would setup a users mailbox on one server and when they would log in to another server the settings would follow them. That does not seem to be the case with Exchange Online. We are having to logon to each RDS server and manually set them up each time they logon to a new one(only for new users). If the user had an old on prem Exchange account that we migrated to the cloud then those settings get over-written and their Exchange Online account comes over no problem. Just trying to figure out a way that will setup the new user EOL accounts when they logon to the new servers. We are using Roaming profiles too if that helps. Maybe some sort of powershell script that I can modify with the new users names when I am setting them up?
Sounds like the AutoDiscovery isn´t working correctly. Please check with the Microsoft Remote Connection analyzer if you see any errors (e.g. as explained in KB 2404385). Here is by the way a good starting point how that should work.