Office 365 directory synchronisation failing for a couple of users (permission-issue)

When I deployed directory synchronisation for our Office 365 (Exchange online) migration I noticed that a couple of users did not sync. 

The synchronisation service manager shows the users failing synchronisation. Here’s what it looks like. It’s the same for both users.

There’s 1 warning and 2 errors in the event viewer which I’ve pasted below.

Can anyone shed some light on this please?


Log Name:      Application
Source:        FIMSynchronizationService
Event ID:      6100
Task Category: Management Agent Run Profile
Level:         Warning
Keywords:      Classic
User:          N/A
The management agent “SourceAD” step execution completed on run profile “Export” with errors.

Additional Information
Discovery Errors       : “0”
Synchronization Errors : “0”
Metaverse Retry Errors : “0”
Export Errors          : “2”
Warnings               : “0”
User Action
View the management agent run history for details.


Log Name:      Application
Source:        Directory Synchronization
Event ID:      0
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
The Management Agent ‘System.Management.PropertyData’ reported  errors on execution.


Log Name:      Application
Source:        Directory Synchronization
Event ID:      0
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Executing export run profile on source MA failed for System.Management.PropertyData. Failed to export objects:


Here’s the fix in my case:

Open Active directory Users and Computers, enable the Advanced features in the View settings and open up the user object that can’t sync. Go to the security tab and then into advanced, check to make sure the box is checked to inherit permissions.

Before you do that you might want to check what permissions are currently assigned and what they will be assigned after inherit permissions is enabled. After all there might be permissions that you do not wish the particular user to have.

That’s all for now.


Cisco WLC, Single SSID, 2 User Groups in Different VLANs

Here’s the scenario:

The customer wanted to provide wireless network access to 2 different groups of users, say sales and technical. The sales and technical user groups have their network privileges restricted by use of VLANs and the customer envisioned have 2 SSIDs, one per user VLAN. Wireless authentication was going to be via a pre-shared key (not my idea!!!).

Here’s the hardware:

2 x Cisco 5508 Wireless LAN Controller (Active & Backup)
130 x Cisco 3500 APs
5 x Cisco 3750 Switches (Core) 24 x Cisco 3650 Switches (Access)
2 x HP DL380 G7 (Server 2008 R2)

I work for an Aruba Networks partner and know that there’s a more elegant solution to what the customer is asking to do when using an Aruba wireless controller but wasn’t aware of a way to do this with a Cisco Wireless LAN Controller.


I installed the Certificate Services role on one server and then installed Network Policy Server role on the other.
Created 1 SSID on the Cisco WLC and put it in a guest VLAN which only has Internet access. Configured the SSID to use 802.1x authentication and pointed it at the NPS server and enabled Allow AAA Override. This override setting is key! It allows you to send back RADIUS attributes from NPS which will specify which VLAN users will be put into upon authentication.

Next NPS was configured with 3 Network Policies. One for sales users, one for technical users and one for domain computers.

Now here’s the good bit:

By configuring the following 3 RADIUS standard attribute types in each Network Policy, NPS tells the Cisco WLC that users authenticated should be placed in a VLAN specified in the “Tunnel-Pvt-Group-ID” RADIUS attributes.

Here are the 3 attributes:

[64] Tunnel-Type (Set this to VLAN)
[65] Tunnel-Medium-Type (set this to 802)
[81] Tunnel-Pvt-Group-ID (Set this to the VLAN ID you wish to put the user in)

Next a wireless group policy was configured with the SSID, Encryption, Authentication and single sign on settings and applied to domain computers.

Note: The domain computers NPS Network Policy is essential so that machines can login before the user attempts to authenticate and therefore computer group policy applies and users can authenticate against the domain.


Dynamic VLAN Assignment with RADIUS Server and Wireless LAN Controller Configuration Example
NPS RADIUS Attributes

Note: This post is mostly for my benefit so I don’t forget! The links above go into more detail on the topic.

4 HP DL380 G6s + HP SmartStart 8.30 + Windows Server 2008 R2 x64 Enterprise Core = FAIL

Customer ABC (not their real name) required a number of servers for a new project they are undertaking where they are moving a solution that is currently hosted to in-house. We analysed the solution and recommended the following hardware all running Server 2008 x64 Core and running as Hyper-V host servers (later in the project I will be installing various 2008 server roles.

4 x HP DL380 G6 (with the following in each)
2 x Quad core processors
18GB of memory
5 x 300GB SAS storage
1 x 4 port NIC

HP DL380 G6

The customer agreed, hardware and software was purchased and sent to site. A couple of days later I went to site and built the 4 servers and installed them in the customer’s new rack. This all went fine.

I ran the RAID configuration and created a 1TB RAID 5 logical disk then ran the HP SmartStart 8.30 x64 CD. Selected install from the SmartStart menu and selected that I wished to install Windows Server 2008 R2 x64 then chose the Enterprise Core version. I would have liked to have the full 1TB as the system partition but only had the choice of a maximum of ~500GB so I chose to use 64GB for the system partition leaving the rest of the space for the Hyper-V virtual machines.

This next part I was doing on all 4 servers at the same time as there is an element of waiting involved in some areas of the installation.

I entered the required information so that SmartStart could create the unattended answer file for the Windows Server installation. I used this customer’s local administrator password and confirmed it. Windows installed and the servers rebooted, excellent I thought…

I was then prompted to login to Windows so I entered the password I gave during the SmartStart install but this was not recognised. Hmm. Tried it on another server as I thought I might have made a typo (although unlikely as I had to confirm the password) but this also fail saying the username or password is incorrect! Tried to login on the other 2 server but the password is failing on them too.

I thought there might have been an issue with the special character that’s in the password however the only special character is + which is the same in US keyboard layout as it is in UK.

Called HP technical support and told them the issue I was experiencing but their response was “You must have typed the password in wrong”. I did mention to them that the same issue has occurred on 4 different servers and during the installation I had to confirm the password twice per server. So that’s 8 times that I typed the password in wrong. I think not. Their only other suggestion was to install Windows manually.

I decided not to go with their suggestion.

I put the “SmartStart” CD back in and reinstalled the Server 2008 R2 Core OS but left the administrator password blank in the SmartStart software. Low and behold I was able to login with the blank password (and immediately asked to set a password).

Please don’t let this smart and usually helpful software trip you up in the same way.