SharePoint versionining is very cool feature, but in time or setting incorrect version limitations can cause performance issues. When this happen you may want to get rid off older draft versions.

Following script is cleans for older draft versions in a library while keeping all major versions. Also you can keep defined number of last major items drafts available.
Note: This script doesn’t delete any major item.

So the reproduce the issue;
I have create a User Profile Property as string (Multi-Value) from User Profile Service-> Manage User Properties. That was the easy part . (Please notice i didn’t select any TermSetId when i creating the property)

We need to “Refresh Schema” of the Management Agent for SharePoint (SPMA) to discover newly created property .Well it succeeded without issue. But there is a problem , when you export the schema.xml of the SPMA you will notice that property marked as “Export-Only” .
dsml:attribute ref="#Rooms" required="false" ms-dsml:isAnchor="false" ms-dsml:allowedOperation="ExportOnly"

Thats means you can not import from SharePoint to Metaverse that property . (It is working in contrawise , Export for SPMA means Metaverse to SharePoint , Import means SharePoint to Metaverse)

So it will not allow you to create “Attribute Flow” other direction (Import) in SPMA Properties. I have faced a very definitive error that is “EXPORT-ONLY”

So i have tried to mitigate this by modify SPMA schema xml . “Export Management Agent then modify the xml and get rid of dsml:allowedOperation="ExportOnly" , and again update management agent with new xml. But no luck.
Well it is worked at the beginning and i able to export my value to the AD until when i need to “Refresh Schema” for SPMA . I have faced following error in event viewer.

After hours of investigation noticed that it is related with TermSetId in Profile DB.
I have checked and compare the properties in the database and noticed if i create a multi-value string even without termset id it is storing an emty guid inside ,well the other properties was null. So I have done a manuel set NULL (which is not supported) to test. Voila , now i can able to refresh schema again and everithing works fine. But this is not a valid resolution . It is not supported . And what if i want to use Term Set Id with that Profile Property ?

Luckly it was resolved by SharePoint team long time ago . But not documented any where or i didn’t find it.

Resolution:
SharePoint connector (build 4.3.2036.0 or higher) have a new setting .Enabling the new setting “Import auto-updated attributes” on the Connectivity tab of the SharePoint Connector allows us to import an attribute that has a TermSetID other than NULL.

SharePoint outbound email messages incorrectly try to authenticate to SMTP servers that support Generic Security Service Application Program Interface (GSSAPI), Kerberos, or NTLM authentication. This may prevent email messages from being sent. After you install this update, SharePoint sends email messages anonymously without authentication.

Well it is confusing, as you may know, out of the box mail configuration for SharePoint always anonymous. Thats correct.
But in some special configuration applied by customers to force SharePoint processes (w3wp or owstimer) to authenticate with their identities to Exchange server; If aspnet:AllowAnonymousImpersonation settings was disabled for Authenticated users (well it doesn’t work for anonymous users at all) it may work.

The problem of this kind of authentication is incorrect ,not expected for SharePoint and Microsoft considered this is a Security Issue. As Microsoft said by design it has to be anonymous. With that Security fix will prevent this. SharePoint will be always use anonymous authentication through SMTP servers.

For customers who interested force authentication , well there’s no way to disable the anonymous-only behavior but we have valid workaround for that:

If you are using Exchange, you can set up a separate receive connector configured as externally secured, and restricted to the IP addresses of the SharePoint server(s) in their environment. This will allow SharePoint to send e-mails anonymously through this receive connector, but the connector will treat the e-mails as if you were authenticated. All other SMTP clients will continue using the regular receive connectors and any authentication policies associated with those receive connectors.

Set up a smarthost SMTP relay that will accept e-mails anonymously from the SharePoint server(s), and then relay them to the company’s SMTP infrastructure using authentication.