After a brief diversion, I’m returning to my series on SharePoint with RMS. This post finishes off the baseline considerations, although there’s a lot more to say. But at last, in this post, we’ve reached the point where we know that RMS thinks I’m cool – so now what? Or if you prefer, I’m taking a look at the RMS Use License that is typically embedded in Microsoft Office documents, or in other cases might be associated with a client’s machine.
The Use License that RMS issues acts like an offline enforcer of allowed rights. The rights granted by RMS and the duration they persist define what a user can do with their offline copy of RMS-protected content and how long they can continue to take those actions before they need to re-visit SharePoint and the RMS infrastructure in order to claim fresh rights. Since rights persistence is defined by the owner(s) of a SharePoint list, the impact of those settings should be well understood by any users that have this control.This post focuses on what a user can do offline once RMS has done its job, and the user’s experience once those rights expire, bringing the tension between valid offline access versus timely rights revocation to the fore.
You will notice I’m talking about offline access a lot here. When I say “offline” in reference to RMS-protected content, I mean the documents that have already been encrypted by RMS and decrypted/opened by a user. I say the files are offline because the original unencrypted content still resides in the SharePoint content database. Any edits that RMS allows a user to make to the offline content need to be saved back to SharePoint if they will persist over time. Continue reading “RMS Use Licenses, Offline Access and Rights Revocation with SharePoint 2010”
I’ve recently been involved in MOSS 2007 farm topology discussions with a client that was interested in using the Split back-to-back topology. After a lengthy troubleshooting and escalation process we’ve identified some problems with this TechNet extranet farm topology guidance in conjunction with Microsoft Tier 2 support. In short, the TechNet document identifies some supported topologies that span domains, but this incident has raised questions about:
- The acceptable placement of server roles in those topologies.
- Supported domain trust directions.
- Alternate Access Mappings requirements.
- Picking people from other domains.
This is an account of the relevant issues and the steps that we took to reach our conclusions. Continue reading “SharePoint Server 2007 cross-domain farm topologies”
We’ve identified that the user profile import in the SharePoint 2010 public beta can’t handle hyphens in domain names. The import will succeed but the portion of the domain name preceding the hyphen will get trimmed. When a user logs on a new profile is created but it is orphaned from the imported data. In principal we’ve been able to work around this by migrating the user profiles with STSADM (thanks to my colleague Martin Hatch for the suggestion) but we haven’t put this approach to the test over a sufficient period of time to be able to recommend it firmly yet. We also don’t have a mechanism for triggering the update for newly-imported users but it shouldn’t be rocket science to come up with a solution to that problem for the duration of the beta.
Microsoft have confirmed this is a problem in the SharePoint 2010 public beta and that a fix will be included in the next release. Their response was on a closed beta forum, so I can’t include that detail here, but this is my description from MSDN: Continue reading “Hyphens in domain names get trimmed from account names in SharePoint 2010 User Profile Import”
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.