Tired of broken links when someone moves a document within a site collection? Tired of nasty URL’s for a document buried deep in a doclib?
SharePoint 2010 includes a new Site Collection scoped Feature called the Document ID Service.
To enable this feature you can go the old and tired route of Site Settings -> Site Collection Features (under Site Collection Administration) or you can launch the SharePoint 2010 Management Shell and run the following:
PS C:\Users\blairb> Enable-SPFeature -id docid -url <site collection url>
Viewing the properties of a document in the document you will see your document now has a field called Document ID:
Note that for existing documents some action has to be taken on the document to cause a Document ID to be generated (like check-in/check-out.) Any new documents will have a Document ID generated on upload... Or you can go into Site Collection Administrator and force a timer job to stamp all the documents.
If you grab the link off the Document ID field you will have a URL that looks something like this:
http://<sitecollectionurl>/_layouts/DocIdRedir.aspx?ID=MFSHF5F7ZUF5-1-1
As you can see from this URL we have a new ASPX page in the layouts directory called DocIdRedir.aspx that takes a Doc ID as a querystring parameter. You can use this link to provide others with a consistent link to your documents. Even if I take the document and move it to another folder in the doclib or another doclib in the site collection the same Doc ID will still find the document.
UPDATE: A colleague asked me about Document Sets (another bad ass new feature in 2010 that lets you work with a set of files as one entity) and Document ID’s. The Document ID Service Features tags an ID on the Document Set AND on each individual file in the set. Fantastic.
Since my customer is using Data Protection Manager 2007 to protect their SharePoint Farm workloads - they decided they wanted to set all the SharePoint databases to use the Simple Recovery Model. They have 30+ Farms so they needed a way to do this quickly per each Farm.
The following SQL script creates a Stored Procedure that will loop through all the Databases in the SQL instance, skipping the system databases, and setting the rest of the databases returned to use the Simple model:
USE [master]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE procedure [dbo].[SetSharePointRecoveryModel]
as
/* variables */
declare @dbname varchar(80)
declare @dbmodel varchar(80)
declare @msg varchar(120)
/* create a cursor for all the databases */
declare system_databases cursor for
select Name, Recovery_Model_Desc from Sys.Databases
open system_databases
fetch system_databases into @dbname, @dbmodel
if (@@fetch_status = 2)
begin
print 'No databases found.'
close system_databases
return
end
while (@@fetch_status = 0)
begin
if (@dbname = 'tempdb' or @dbname = 'master' or @dbname = 'model' or @dbname = 'msdb')
begin
select @msg = @dbname + ' -- Not updating recovery model of system databases.'
print @msg
end
else
if (@dbmodel = 'FULL')
begin
EXECUTE ('ALTER DATABASE [' + @dbname + '] SET RECOVERY SIMPLE WITH NO_WAIT;');
select @msg = @dbname + ' -- Set to SIMPLE.'
print @msg
end
else
begin
select @msg = @dbname + ' -- Already set to SIMPLE.'
print @msg
end
fetch system_databases into @dbname, @dbmodel
end
close system_databases
deallocate system_databases
This creates the sproc in the Master database. Using it then is simply:
USE Master
EXEC dbo.SetSharePointRecoveryModel
More information on SQL Recovery Models:
Overview of the Recovery Models
http://technet.microsoft.com/en-us/library/ms189275(SQL.90).aspx
This one is short and sweet. My customer has federated partners so we use ADFS to allow these partners the ability to access and collaborate with our SharePoint portal. One of our amazing developers wrote code to create user profiles in the ADFS enabled SSP (an extension of the normal Windows auth'ed SSP.) Part of this new process pulls in their email address from the claim and inserts it in the Work E-mail profile property which enables alerts to function properly. Unfortunately alert e-mails, including the initial alert setup e-mail were not being delivered to these new users. We verified that the e-mail address was correct in the profile and that normal e-mail could flow to the users. Off to the ULS logs we went, after turning up E-mail and Timer Jobs to Verbose. We found the Immediate Alerts job was logging the following:
The e-mail address '<email address>' is unknown.
Where <email address> is a valid address in the ADFS account partner.
I found this KB – which has to be the most confusing KB I think I've seen to date:
"The email address '<EmailAddress>' is unknown" error message when you add a user to a Windows SharePoint Services 3.0 or Windows SharePoint Services 2.0 Web site
http://support.microsoft.com/kb/838109
… ok same error message although not related at all. Message tracking on the Exchange Server that the SharePoint farm was configured to relay through did not show any messages arriving there bound for the ADFS Partner organization (expected – just verifying.)
Exchange 2003 SMTP Virtual Server was set to "Only the List below" with an empty list and the "Allow all computers which successfully authenticate to relay, regardless of the list above.
Unfortunately there is not a way for SharePoint to send credentials when sending alert/notification e-mails. So just to verify this is a relay issue - telnet time…
From a command prompt:
telnet
set localecho
open ex01.contoso.com 25
where ex01.contoso.com is the server specified in Outgoing E-mail Settings.
ehlo litware.com
where litware.com is the server domain of the SharePoint user to whom the alert is being sent.
mail from: johndoe@litware.com
where johndoe@litware.com is the e-mail address of the external user
250 2.1.0 email….Sender OK
rcpt to:sharepoint@contoso.com
where sharepoint@contoso.com is the from address specified in Outgoing E-mail Settings.
If you get this:
550 5.7.1 Unable to relay for sharepoint@contoso.com
If you get this:
250 sharepoint@contoso.com… recipient ok
Then your e-mail will be sent successfully.
In Exchange 2003 we could add the IP address of the SharePoint servers to the Relay list in the SMTP virtual server. In Exchange 2007 - check out this article: http://msexchangeteam.com/archive/2006/12/28/432013.aspx
Some companies do not allow wildcard * SSL certificates – but do allow certificates with multiple subject alternative names. Unfortunately there is not a way to easily implement this in MOSS via the GUI. I had a customer that required this – so I figured I'd share what I found…
First:
Verify all host names are in DNS and correct
Verify you have an SSL cert with the SAN's you need and that certificate is available on each WFE.
Verify all sites are created/extended and currently NOT using SSL.
MOSS is the main site - Default Zone
MOSSANON is the site Anonymous Access enabled - Internet Zone
MOSSEXTRANET is the site that would be FBA or some other auth mechanism - Extranet Zone
Change the AAM's for each zone through Central Administration:
From:
To:
From:
To:
From:
To:
Assign the certificate to all 3 websites - only the first one applied will start - this is to be expected.
One each WFE navigate via command prompt to <System Drive>:\Inetpub\AdminScripts
Type the following command at the command prompt for each host header in this format :
cscript.exe adsutil.vbs set /w3svc/<site identifier>/SecureBindings ":443:<host header>"
NOTE: Site Identifier can be obtained in the IIS MMC:
So in our example:
cscript.exe adsutil.vbs set /w3svc/<site identifier>/SecureBindings ":443:moss.litware.com"
cscript.exe adsutil.vbs set /w3svc/<site identifier>/SecureBindings ":443:mossanon.litware.com"
cscript.exe adsutil.vbs set /w3svc/<site identifier>/SecureBindings ":443:mossextranet.litware.com"
Run IISRESET
Repeat this on the other WFE's
Verify all sites are responding:
Troubleshooting:
Follow sequence of steps in specified order – very important!
Verify all sites are started in IIS and no errors reported.
Verify by Viewing the SSL cert on each website that the SSL cert has a matching private key.
One of my customers recently found that someone in the process of working with SharePoint Content Types had renamed one of the built-in Site Columns - Title - to something else… If you attempt to change the Site Column back to "Title" you get this error message:
"The column name that you entered is already in use or reserved."
This is discussed in the following KB Article:
Error message when you try to change the name of a site column back to its original name in Windows SharePoint Services 3.0: "The column name that you entered is already in use or reserved." http://support.microsoft.com/kb/923589
In the article there is an example of C# code to programmatically access the Field object in question and change the name back to the correct/desired name. Let's see if we can make this short and sweet with PowerShell…
I've got PowerShell installed on one of the members of my Farm so that I have easy access to the SharePoint object model.
# First we need to tell PowerShell how to use SharePoint objects:
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
# Next we create a site object by created a variable and providing the URL of the site in question.
$site=[Microsoft.Sharepoint.SPSite]("http://<your site>")
# Next we create a web object and open it from the site.openweb method
$web=$site.openWeb()
# Next we create a field object and site it to the name of the field that we want to correct - in this case: Title
$fld = $web.Fields.getFieldByInternalName("Title")
# Next we set the Field object's Title attribute to the name we want to be displayed, again in this case: Title
$fld.Title = "Title"
# Next we tell SharePoint that we want this change to apply to all Lists
$fld.PushChangesToLists = $true
# Finally we make the change official.
$fld.Update()
PowerShell for Windows 2003 SP1 can be downloaded from here:
X86 - http://go.microsoft.com/fwlink/?LinkID=75790&clcid=0x09
X64 - http://go.microsoft.com/fwlink/?LinkID=75791&clcid=0x09
If you've gotten daring and are playing around with MOSS SP1 on top of Windows 2008 - PowerShell is simply a one-line command from the Windows 2008 Command Prompt:
ServerManagerCmd -i PowerShell
Hope this helps!
