Unfortunately the fix in MIM does not work as expected so this will have to wait. When calling Set-MIISADMAConfiguration the ADMA configuration is not updated as expected. Until these problems are fixed in MIM we still need our code to modify the ADMA XML file before importing it, and the user still needs to set the ADMA password manually.

Phantom Partition

The Set-MIISADMAConfiguration has a parameter that allows you to specify the partitions to connect to. The command does not remove existing partitions, it just leaves them in the configuration which creates other problems.

Partitions Are Not Selected

The Set-MIISADMAConfiguration 'partitions ' parameter does not work when you specify more than one partition. For SharePoint sync we need to read the default naming context and the configuration naming context, so having just one partition work breaks us.

Setting the ADMA Password

The Set-MIISADMAConfiguration command can set the ADMA password but we can't use it because it also hacks up the run profiles. Workaround is for the user to enter the password using the Synchronization Service Manager UI.

from pnp-tools.

This isn't entirely accurate....

Set-MIISADMAConfiguration CAN be used today on build 4.3.2195 to update the credentials, avoiding the administrator having to enter the password using MIISCLIENT.EXE. It can also be used to directly allow selection of multiple Sync containers.

The only downside to this is that all containers within the configuration partition are selected, rather than just CN=Partitions. Now, that's not as tidy as it should be (i.e. a truly fixed cmdlet allowing appropriate Container and Partition specification). However it is a viable approach to avoid having to open up the AD MA to touch up the password. There is zero impact on Run Profiles for the ADMA.

 $Partitions = "$($RootDSE.defaultNamingContext);$($RootDSE.configurationNamingContext)"
 Set-MIISADMAConfiguration -MAName ADMA -Credentials $ForestCredential -Forest $ForestDnsName -Partitions $Partitions -Container $Containers -Verbose

$Containers being a semi-colon delimited list of OUs to sync (within the default naming context).

This works just fine, in conjunction with removing the inclusion of the original $OrganizationUnit param in the fix up for the domain partition.

The -Partitions parameter only "does not work" when you then add a Container from the second/third partition. As per the code above, both partitions are included. The appropriate OUs are included in the default naming context, and the entire Configuration context is included.

Phantom partitions are a non issue in this scenario as there are none to "unselect".

Obviously a fully fixed cmdlet is what we want, and whilst not perfect avoiding a manual password touch AND allowing multiple container selection is far more customer acceptable. And it works just fine. If a MIM fix isn't on the horizon, i'd urge you to make these changes, which customers are doing already.

from pnp-tools.

Think this boils down to bloated/phantom config versus manual steps. I'd thought bloated/phantom config wasn't acceptable but hear your feedback. I'll try again, maybe this is acceptable until the MIM cmdlet is fixed.

Thanks for testing and providing feedback!

from pnp-tools.

Are there any news on this topic?

from pnp-tools.

how important you your customers is the credential fix up, @andikrueger ?

from pnp-tools.

It would be great to set the credentials during the first setup without the need to open the MA in MIM.
In my latest customer projects, this was not a show stopper, but it is somehow uncool, when the password must be set separately. I’d like to see this fixed. If I think about more complex setups (several SPs), it is annoying to set passwords several times.

from pnp-tools.

Thanks for the feedback @andikrueger, unfortunately that functionality (setting the credential) in the MIM Sync product breaks part of the configuration so at the moment we're unable to use it.

from pnp-tools.

We closed this issue as it had not activity within last 180 days. This is a generic process we have decided to perform for issues, which have not been explicitly marked still to be "work in progress" based on tags. We are performing this cleaning to make sure that old issues that have already been solved (but not closed) or are no longer relevant are cleaned out and make the issues more manageable. If this issue still valid, we would ask you to open a new issue and follow the guidance in the issue template related on the recommended location. We do apologize any inconveniences this might cause. Please do remember that issues in the issue lists are also messages for others in the community, so you can also check if you can assist on any of them. “Sharing is caring!”

from pnp-tools.