Due to IDB-799, the schema retrieval for MOSS List and 2007 User Profile does not work:

As a workaround, the connector factories should call CreateComponent to recreate the connector in the schema retrieval rather than relying on the connector repository.

As per our discussion - the SharePoint2010UserProfileConnector and 2007 User Profile connector requires an account field to be the first key for ModifyAnchor to work.

A determination should be made about whether the AccountName field in SharePoint can change, and if so whether the current field name can be retrieved.

This raises a question about the concrete requirements for a fixed schema in a larger sense, and what a fixed schema is event meant to be.

There are a number of ways of potentially thinking about fixed schemas:

e.g.

• A fixed schema field is a field that cannot be changed from a concrete/constant field defined in IDB
• A fixed schema field is a field that must be present, and needs to be requested from the target identity management store.
• A fixed schema field is a field which must be a key or must have a name, or must be readonly etc., but all other values can change
• A fixed schema field is there to help, and that takes precedence over whether it doesn't necessarily need to be in the schema (but will always be in the target store).

etc. etc.

Update connector to work with SharePoint 2013.

A change was made to the domain casing so that they are consistent, in this case I added .ToLowerInvariant() to user.Domain (AccountNameToDistinguishedNameAdapter.cs, Line 43)
As i mentioned this might not be applicable to all sites, so an option to enable/disable would be appropriate. Possibly also an option to select between Upper or Lower case might be useful too.

I’m troubleshooting an issue at TAFE where the Unify web service for managing user profiles is throwing HTTP400 errors currently and was hoping you might be able to provide some guidance on where to look next.

On Richard’s advice I’ve done a WCF trace capture from the Identity Broker side and have found the following error occurring:
System.Net.Sockets.SocketException (0x80004005): An existing connection was forcibly closed by the remote host
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)

I’ve looked through the Sharepoint logging and not found anything indicating what could be happening – therefore was hoping that you might be able to advise if there is a way to capture logs/debug the Unify solution that has been deployed within Sharepoint.

The list connector is not returning errors on saves, giving the appearance that failed exports are successful. Handling should be added to the ModifyListItemAndReturnId method such that the connector can handle messages such as the following (where an update is attempted on a non-existent list item):

<Results xmlns="http://schemas.microsoft.com/sharepoint/soap/"><Result ID="1,Upd
ate"><ErrorCode>0x81020016</ErrorCode><ErrorText>Item does not exist

The page you selected contains an item that does not exist.  It may have been de
leted by another user.</ErrorText></Result></Results>

Estimate includes testing

Hi Gents,

I've Started testing the existing SharePoint connector for compatibility with SharePoint 2013.

So far I've installed the 2010 web service into SharePoint and confirmed it's install via the install guide. https://unifysolutions.jira.com/wiki/display/IDBSP40/Installing+the+SharePoint+2010+WCF+Service

I've also installed the connector and performed a successful connection test with the existing agent.

The first issue I've encountered is around the schema discovery components. On attempting scheme discovery, the following error is thrown:

The schema for 'SPTest Connector' connector was not updated for the following reason: System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: Value cannot be null.
Parameter name: serviceContext (Fault Detail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is:
System.ArgumentNullException: Value cannot be null.
Parameter name: serviceContext
at Microsoft.Office.Server.UserProfiles.ProfileManagerBase..ctor(SPServiceContext serviceContext)
at Microsoft.Office.Server.UserProfiles.ProfileManagerBase..ctor(SPServiceContext serviceContext, Boolean ignorePrivacy)
at Microsoft.Office.Server.UserProfiles.UserProfileManager..ctor(SPServiceContext serviceContext, Boolean IgnoreUserPrivacy, Boolean backwardCompatible)
at Microsoft.Office.Server.UserProfiles.UserProfileManager..ctor(SPServiceContext serviceContext)
at Unify.Connectors.SharePoint.SharePoint2010WCFService.UNIFYIdentityBrokerService.SharePoint2010UserProfileService.GetSchema()
at SyncInvokeGetSchema(Object , Object[] , Object[] )
at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)
at System.ServiceModel.Dispatcher.DispatchOperation...).

I've discussed this with Shane, and will be submitting a Source Control request for access to the SharePoint connector repository. In the absence of Adam, I will be investigating this and any other issues that arise from integrating with the new version of SharePoint.

The following exception was displayed when attempting schema discovery for my WSS list connector:

Could not find endpoint element with name 'BasicHttpBinding_ISharePoint2010UserProfileService' and contract 'OrganizationProfileManager.ISharePoint2010OrganisationProfileService' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this name could be found in the client element. 

This is after seeing a similar error, locating QDET-213 (I could not find any config instructions on https://unifysolutions.jira.com/wiki/display/IDBSP40/Microsoft+SharePoint+List+Connector) and adding the following sections to the Unify.Service.Connect.exe.config file:

        <binding name="BasicHttpBinding_ISharePoint2010UserProfileService"
					   
          closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00"
          sendTimeout="10:00:00" allowCookies="false" bypassProxyOnLocal="false"
          hostNameComparisonMode="StrongWildcard" maxBufferSize="204003200"
          maxBufferPoolSize="524288" maxReceivedMessageSize="204003200"
          messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
          useDefaultWebProxy="true">
          <readerQuotas maxDepth="32" maxStringContentLength="65536000" maxArrayLength="65536000"
            maxBytesPerRead="65536000" maxNameTableCharCount="65536000" />
          <security mode="TransportCredentialOnly">
            <transport clientCredentialType="Ntlm" proxyCredentialType="None"
              realm="" />
            <message clientCredentialType="UserName" algorithmSuite="Default" />
          </security>
        </binding>
        <binding name="BasicHttpBinding_ISharePoint2010OrganisationProfileService"
          closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00"
          sendTimeout="10:00:00" allowCookies="false" bypassProxyOnLocal="false"
          hostNameComparisonMode="StrongWildcard" maxBufferSize="204003200"
          maxBufferPoolSize="524288" maxReceivedMessageSize="204003200"
          messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
          useDefaultWebProxy="true">
          <readerQuotas maxDepth="32" maxStringContentLength="65536000" maxArrayLength="65536000"
            maxBytesPerRead="65536000" maxNameTableCharCount="65536000" />
          <security mode="TransportCredentialOnly">
            <transport clientCredentialType="Ntlm" proxyCredentialType="None"
              realm="" />
            <message clientCredentialType="UserName" algorithmSuite="Default" />
          </security>
        </binding>
      </basicHttpBinding>
    </bindings>
    <client>
      <endpoint binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ISharePoint2010UserProfileService"
      contract="UserProfileManager.ISharePoint2010UserProfileService" name="BasicHttpBinding_ISharePoint2010UserProfileService" />
      <endpoint binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ISharePoint2010OrganisationProfileService"
      contract="OrganizationProfileManager.ISharePoint2010OrganisationProfileService" name="BasicHttpBinding_ISharePoint2010OrganisationProfileService" />
    </client>

Note the wording in the error text - specifically that the element name it claims is missing*UserProfileService* but the contract contains OrganisationProfileService. When I tried modifying the above config to reflect this I still got an error - so I am thinking there may be a build issue?

On setting the RecordId attribute to a validator of any type other than "long", the below error message occurs. This field should be of type 'long', with the error messages suggestion of 'guid' being incorrect (and it will validate as an error if attempted).

Service cannot be started. Unify.Framework.UnifyServerInitializeException: SharePoint 2010 Organization Profile connector requires a single key of RecordId, which is expected to be of type Guid. ---> Unify.Communicators.SharePointConfigurationException: SharePoint 2010 Organization Profile connector requires a single key of RecordId, which is expected to be of type Guid.
   at Unify.Connectors.SharePoint2010OrganizationProfileConnector..ctor(Guid connectorId, IEntitySchema schema, String name, IConnectorGroup connectorGroup, IConnectorEntityPartitionContextFactory contextFactory, IGenericWCFCredentialsCommunicatorInformation communicatorInformation, Int32 pageSize, Int32 maxItemsInObjectGraph, Boolean replaceWideAmpersands)
   at Unify.Connectors.SharePoint2010OrganizationProfileConnectorFactory.CreateConnector(XElement communicatorElement, IGenericWCFCredentialsCommunicatorInformation communicatorInformation, Guid connectorId, IEntitySchema schema, String name, IConnectorGroup connectorGroup, IConnectorEntityPartitionContextFacto...

The below for example will trigger the error.

<entitySchema>
            <field name="UserProfileGUID" validator="guid" />
            <field name="AccountName" validator="dn" />
            <field name="RecordId" validator="string" key="true" readonly="true" />
            <field name="DisplayName" validator="string" />
			<field name="PreferredName" validator="string" required="True" />
            <field name="Members" validator="dn.multi" />
            <field name="ParentRecordId" validator="long" />
          </entitySchema>

correct value documented at https://unifysolutions.jira.com/wiki/display/IDBSP305/Microsoft+SharePoint+2010+Organization+Profile+Connector

Hi,

I notice that it is very clearly stated that the Sharepoint List connector is for Sharepoint 2007. I don't see a 2010 equivalent.

Is there an expectation that it will work with Sharepoint 2010? If so, how does the configuration need to differ? I notice that there are distinct differences between the 2010 communicator and the 2007 communicator for the other connectors

This is an item that has been referenced in a couple of other issues but requires its own issue so it can be tracked specifically. I have identified what I believe is a major problem with the Sharepoint Connector with Identity Broker. It relates to the fact that a case difference in the domain name (and perhaps the account name as well - unsure).

For example if the case changes or appears to change from say CN=T00000003539,DC=cad to CN=T00000003539,DC=CAD or the other way around, Identity Broker triggers a migration of the user profile. The result is that the Sharepoint Profile is deleted. We then ended up with what looked like duplicates in ILM - both with the same account name but one entry having the DN as the GUID rather than the correct account name - probably because Broker had the old value but was not able to confirm the new or something similar - not pretty.

Working with Peter Sullivan, we replicated the problem in a vanilla Sharepoint Install by doing the following:

1. Created a user in AD and running a Profile Import from MOSS against AD. Added some profile information against the user
2. Searched for the user and confirmed that they are in fact present
3. Running a profile migration as follows (BTW - you could have any combination of case including the same case):
stsadm -o migrateuser -oldlogin DEV\peter -newlogin dev\peter -ignoresidhistory
4. Searched for the user again - they were no longer present in MOSS
5. Ran another profile import against AD and the user re-appeared but with no profile information against them

Hence it appears as if this could be a major problem. It is no doubt a bug with the Sharepoint API's but it has catastrophic implications for the management of profiles. I managed to destroy over 700 profiles this morning in production when this happenned to occur.

Can you please investigate and attempt to reproduce? In the meantime I may revert the solution back to an account that does not have the priveleges to run a migration in order to stop this ocurring in production from now on, unless you have a tactical recommendation.

I have attached the logfile from Broker as well as the screenshot of the ILM view of things.

thanks,
Craig