Most IT Professionals with SharePoint 2010 experience will be familiar with the initial configuration complexities of the User Profile Service Application but it’s probably less well-known that there are additional requirements to set up profile property export, and that some properties have further requirements still. SharePoint 2010 allows properties to either be imported or exported (but not both, out of the box). The most basic of these requirements for Active Directory export are the Write All Properties and Create Child Objects permissions on the OUs where data will be written by SharePoint.
We initially followed Matthew McDermott’s Profile Image Export suggestions but in our case these steps were insufficient, as detailed below. That article was written while SharePoint 2010 was a beta product. The User Profile Service Application changed since that release and is now configured differently, so it doesn’t surprise me that our experience differs.
You might wonder why we spent this much effort just to get a picture in Active Directory (of all places). While we think it’s important to have this knowledge for our clients and delegating photo selection to end users can drive SharePoint adoption, it is also used by the Outlook 2010 Social Connector. When you start using this great new social computing front-end, it just feels incomplete without a photo.
Continue reading “User Profile Picture Export Permissions”
For some time now, IT professionals have been modifying DCOM activation rights in order to keep their System event logs clean. In SharePoint 2010, that fix became slightly trickier, as permissions to modify the DCOM permissions had to be granted through the registry for the IIS WAM REG admin service and oSearch14 DCOM applications. Having made these fixes, I’ve noticed a new breed of DCOM 10016 error.
The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID
to the user <FARM ACCOUNT> SID (S-1-5-21-xxxxxxx….) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.
The CLSID for this COM Server Application is MSIServer, used to activate the Windows Installer Service. You can find this by navigating to HKCRAppId and examining the details there:
Continue reading “Product Version Job: DCOM 10016 strikes again”
Tony Soper, a Senior Technical Writer for Microsoft, has been revealing some interesting new content recently. Both System Center Configuration Manager and Forefront Threat Management Gateway (the successor to ISA) have, “Superflows”, which are described as, “a new Content Type”. After poking around for a bit I found this 8 minute podcast from 2008, where Tony interviews Doug Eby from the SCCM team about Superflows in more detail. They’re, “an interactive flowchart”. A Superflow can ask questions (about an environment, for instance) and a resulting flow will be targeted based on those answers. In the podcast they say this will be extensible in future and that there will be authoring support of some sort, so it will be interesting to see how this sits beside Visio, Visual Studio and InfoPath as a form/flow technology. I’ve asked Tony for more information about that on his blog and was told to watch that space for an eventual release date. I’d recommend this anyway, as his blog is a trove of good information, particularly around Virtualisation.
It’s now a week on from Mark Russinovich’s NewSID retirement announcement and I’ve been watching the feedback since. To give a brief overview, it’s long been a tenant of machine cloning processes that a new machine SID should be generated for each clone in order to prevent conflicts. Mark Russinovich wrote the original NewSID tool for Windows NT and as a Microsoft Technical Fellow today, he supposed that it might not be needed anymore and investigated the implications of retiring it. Obviously, if you haven’t read it yet and you work with machine cloning, you should read the article, but if you haven’t found the time to sift through the 168 comments (and counting), this summary might help clarify things:
Continue reading “NewSID myth implications for SharePoint development”
Gary Lapointe recently released a custom STSADM command for setting the BackConnectionHostNames registry key. The relevant Microsoft KB article recommends specifying each host header with the BackConnectionHostNames key rather than disabling the loopback check, as this check is a valuable security fix. As Gary Lapointe mentions, Spencer Harbar put together some thorough background information on the roots of the fix. Without this command, setup and maintenance can be a bit of a hassle if you have lots of SharePoint applications or lots of Alternate Access Mappings (or if any of this information changes with any regularity). These registry changes need to be made on each web server for any sites with host headers. This includes Central Administration if it’s not configured on <servername:port>. So this could get quite laborious if the farm is fairly large. The UpdateFarm parameter may be particularly helpful in this regard.