Post by: Oliver Wirkus
Posted on: 10/8/2015 11:04:00 PM
Categories: Office 365;SharePoint
I have been promoting Document Management with SharePoint for many years now and I’m still convinced that enterprises will benefit a lot if they move their files from a file-share to SharePoint. Although managing files in SharePoint libraries usually solves a lot of problems enterprises encounter with saving their corporate files to file-shares, there are some issues that impact the user experience negatively. One of these issues has been the way employees access files if the files are moved to different locations. To understand this issue, we need to have a look at the Document Lifecycle first. Document Management is not only saving documents to SharePoint libraries instead of saving them to folders in a file-share. A Document Management System should at least support a basic document lifecycle. A document undergoes different stages during its lifetime. A typical document lifecycle could look like this, but there are also more extensive definitions
Let’s have a look at a common scenario to understand the basics of a document lifecycle. If an important document is created, usually a team is working on this document and this team usually is using a SharePoint team site to collaborate. As long as this document is saved to a document library that is part of this team site, everyone can access this document by its URL – assuming he or she has appropriate permissions. This is what the document lifecycle describes in its ‘Create’ phase.
When the work on this important document has been finished, it is usually reviewed by using an approval process based on a workflow. When the document is approved, it is usually saved to a different SharePoint library. This can be a library for official documents in a company. The document lifecycles refers to this as the ‘Distribute’ phase. It is obvious that this document can’t be accessed by its ‘old’ URL anymore, because it has been moved to a new library and because of that the ‘old’ URL gets invalid. Same is true for the additional steps of a basic document lifecycle. There is another scenario which leads to invalid document URLs. Sometimes it happens that a company decides to restructure their intranet. As soon as documents are moved to a new location, they can’t be accessed by their old URL anymore, because the URL changed because of the move. Same is true if the document is renamed. Let’s see how this looks like. The following screenshot shows a common document library in SharePoint 2016. I just added a new document to this library
To retrieve the URL of this document, we can simply click on the three ellipses. SharePoint 2016 will show a pop-up with the accounts that this document is shared with and it’s URL. The URL of my sample document is looking like this
If this document is moved to a new library, it can’t be retrieved by its URL anymore, because the name of the old library (“Shared Documents”) is part of the URL. Same is true if the document is moved to a different site, because the name of the site (“wirkus”) is also a part of the URL.
SharePoint provides a solution for this by leveraging Document IDs. In simple terms SharePoint is using an internal service to add a unique number to each newly created document. Because this service is running in the scope of a site collection, the IDs are unique only within the same site collection. To overcome this limitation, a custom Document ID provider can be created or a prefix can be configured. If you are interested in how to do this, I encourage you to have a look on this blog post I have published some months ago. Setting up Document IDs is very easy – you only need to activate the corresponding site collection feature
If you add a new document to a library with Document IDs turned on, SharePoint will assign a new Document ID to the document. The URL of the document is looking different now
http//sp2016b-mj/sites/wirkus/_layouts/15/DocIdRedir.aspx?ID=5QUY74FYUPFY-1778240737-2 As you can see, the URL of the document does not contain any document related information now – except of the Document ID. Instead it redirects to a SharePoint page (called DocIDRedir.aspx) and adds the Document ID of the document as a parameter. This page leverages a control that takes the given Document ID and looks for the document. Although this involves an additional step, a user usually does not recognize this additional step when accessing a document by its DocumentID-based URL. The creation of the Document IDs is managed by two different timer jobs just the same way it was in SharePoint 2013
Based on my findings using the current public beta of Microsoft SharePoint 2016 (Version 16.0.4316.1217), it looks like Microsoft just enhanced the Document ID services of SharePoint 2013 a little to make it more user-friendly. That's the reason why I assume, that this service is working in SharePoint 2016 almost the same way as it did in SharePoint 2013. To understand how this service is working internally, we should have a view on the code needed to create a custom Document ID provider. The
basic framework of a DocumentID provider looks like this
Each Document ID provider needs to expose a method that generates a new Document ID. This method is named
GenerateDocumentId(SPListItem item). It is called by passing one parameter only the SharePoint item that should get a new Document ID. The Document ID provider is creating a new Document ID and it internally joins it with the SPListItem it gets when the method
GenerateDocumentId()is called. That’s the reason why the Document ID provider is able to create an internal list of all the Document IDs it has created and their joined documents. The Document ID provider uses this internal list to retrieve documents based on their ID. To leverage that functionality, each Document ID provider exposes another method
GetDocumentUrlsById(SPSite site, string docID).
This method is called by SharePoint to retrieve a document by its DocumentID. Basically this is what the page DocIdRedir.aspx does. This method is called with the current site and the Document ID as parameters and it is supposed to return the URL of the joined document. If the document can’t be found in its internal list, each Document ID provider is using the SharePoint Search Index to retrieve the URL of the document. In the end this is the reason why SharePoint is able to retrieve a document by its Document ID even if this document has been moved to another site collection. Although a different Document ID provider is involved if the document has been moved from one site collection to another site collection (because a Document ID providers is site collection-scoped), this different provider can still use the SharePoint search to retrieve the document.
Based on the current beta version of SharePoint 2016 it appears, that Durable Links are the ‘old’ DocumentIDs with minor enhancements. Post by: Elizabeth Gorbunova
Posted on: 9/17/2015 5:27:00 PM
Categories: Office 365
Trying to remove one of the existing domains from your Office 365 tenancy? This should be pretty easy as long as the following criteria are met 1. Domain is not used for UPN addresses2. Domain is not used for SMTP addresses associated with your recipients or Lync online users If you try to remove the domain prior to meeting conditions above (for instance by running Remove-MsolDomain –force) you will get the error saying Unable to remove this domain. Use Get-MsolUser –DomainName <domain name> to retrieve a list of objects that are blocking removal. Depending on how your O365 users were created (through Directory Synchronization or directly in O365) you will either need to update UPNs and remove those addresses from your on-premises Exchange recipients or Office 365 cloud accounts. Once the UPNs are changed and domain is released from recipient addresses, you can confirm that domain is not in use by executing the following cmdlets below. CONNECT TO O365 FROM POWERSHELL $UserCredential = Get-Credential $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https//outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection Import-PSSession $Session Connect-MSOLService CONFIRM THAT DOMAIN IS NOT IN USE To confirm that domain is not used for UPN addresses Get-msoluser –DomainName "domain.com" (where "domain.com" is the domain you are planning to remove from O365) To confirm that domain is not used for SMTP addresses Get-recipient –ResultSize unlimited | where $_.EmailAddresses –match "domain.com" To confirm that domain is not used for E-mail addresses associated with MSOL Groups Get-msolgroup –All |where $_.ProxyAddresses –match "domain.com" Once all 3 PowerShell scripts come back clean you can remove the domain from O365 by running Remove-MSOLDomain –DomainName