active-directoryazureazure-active-directorysynchronization
I am syncing our local AD (from SBS 2011) to Azure AD using the DirSync tool, but since a few days I get an error like the following (translated from local language):
The object can't be updated in Windows Azure Active Directory, because the attribute "AccountEnabled" is invalid. Update this value in your lokal directory service.
Does someone know what this attribute is about and how I can fix that?
I also get a "Local ID of the object" – can I search that object somehow in my local AD?
@MDMarra: Thanks for the hints, so I did:
The users from O365 can be exported by powershell using
Get-MsolUser | Select-Object City, Country, Department, DisplayName, Fax, FirstName, LastName, MobilePhone, Office, PasswordNeverExpires, PhoneNumber, PostalCode, SignInName, State, StreetAddress, Title, UserPrincipalName | Export-Csv C:\Temp\Azure_Export_2014_12_05.csv -Encoding UTF8
This exports all columns to CSV where I could find a mapping that looked appropriate. Those are not all columns, but many of them cannot be mapped to attributes in AD. Others, like the password, cannot be exported.
To import the users to AD, run in powershell
import-csv C:\Temp\Azure_Export_2014_12_05.csv -Encoding UTF8 | foreach-object {New-ADUser -Name ($_.Firstname + "." + $_.Lastname) -SamAccountName ($_.Firstname + "." + $_.Lastname) -GivenName $_.FirstName -Surname $_.LastName -City $_.City -Department $_.Department -DisplayName $_.DisplayName -Fax $_.Fax -MobilePhone $_.MobilePhone -Office $_.Office -PasswordNeverExpires ($_.PasswordNeverExpires -eq "True") -OfficePhone $_.PhoneNumber -PostalCode $_.PostalCode -EmailAddress $_.SignInName -State $_.State -StreetAddress $_.StreetAddress -Title $_.Title -UserPrincipalName $_.UserPrincipalName -AccountPassword (ConvertTo-SecureString -string "Secret!" -AsPlainText -force) -enabled $true }
This creates new users with the name Firstname.Lastname. Other attributes like SignInName could not be used because they are not a valid AD account name.
Country cannot be imported because AD requires the country to actually exist while O365 accepts free text.
The password will be set to "Secret!", because if no password is provided, the account will be created, but disabled.
It may be handy to edit the CSV-file in Excel or something, but I would recommend using PowerShell only. Excel deletes leading zeros from phone numbers or reformats other stuff. Also, mind UTF8.
For the critical requirement:
Yes it can be achieved after you enabling Azure AD Domain service feature and wait for the user accounts & credential hashes been synchronized successfully from Azure AD to Azure AD DS managed domain.
For the other two questions:
The Enable Azure AD Domain service feature is located on the Configure tab of your Azure AD page (Azure classic portal) like below. The more details can be found in the docs here.
The sync from Azure AD to Azure AD DS managed domain is started automatically and one-way/unidirectional on background. More details here.
Additionally, if your users are synced from on-premises AD. Don't forget to configure the password synchronization (cannot be ADFS sync here) with NTLM and Kerberos credential hashes to make sure the synced users can use their corporate credentials to login the servers & services in the managed domain. More details here for reference.
Best Answer
I know this is an old post, but recently had a flood of emails with the same error. It seems to have started after I ran 'full sync' on just the 365 connector.
The emails stopped after a doing a proper full import and sync. With the recent version of Azure AD Connect the PowerShell command for this is: