In one of my projects we are thinking about using Office 365 for an extranet scenario. A good story for another blog post. Depending on the plan we use, up to 10.000 external users could be invited to collaborate in a SharePoint site. See the service description for further details.
One question we had was, how can we determine, how many external users are invited to any of the sites. The answer to this question is very simple. With the SharePoint Online Management Shell we can use the cmdlet Get-SPOExternalUser. The result shows all external users currently in use in any of the sites.
Just for your information, there is also a cmdlet to remove an external user: Remove-SPOExternalUser.
Today we had an interesting discussion about SystemUpdate. The issue was that the metadata of a file should be updated automatically under special circumstances. I normally think about anything unusual in these cases and asked, what will happen, when a file is checked out by a user. The answer was, we will use SPListItem.SystemUpdate() that directly modifies the content in the database. I am a little bit wary in these cases and made a little test with a simple console application. This application gets a file (SPWeb.GetFile()), gets the item of this file (SPFile.Item) and does a simple modification in the title field. This simple piece of code was completed by the call of SystemUpdate() of the item.
To do the test, I logged in with another user and checked out the file our test should run with. Then I started the console application (not with the user, who has checked out the file J), and the code was executed without any error. That was not what I expected. I thought we will get an exception. But ok, having a look in the properties of our file I could see that the title field was modified, when I accessed the properties with the user, who ran the console application. The user, who has checked out the file, didn’t see this modification. From his point of view, the content of the title field was the same as when the file was checked out. I then checked in the file and…
… the modification in the title field was gone. Using SPListItem.SystemUpdate() will not do the trick, when you try to modify the metadata of a checked out file.
I did my test with SharePoint 2013, but I believe, older versions will behave identically.
As in Windows Server 2008 & Windows Server 2008 R2, it is necessary to activate the Desktop Experience feature, when you try to save your Office documentes to SharePoint 2013 in your development environment. But if you try to activate this feature in the Add Roles and Features Wizard in Windows Server 2012, you won’t find it.
But it’s still there. Just scroll a little bit down to the User Interfaces and Infrastructure feature, and within this feature you will find the Desktop Experience.
As in the old versions of Windows Server, the Ink and Handwriting feature needs to be enabled, but that is done automatically.
Today a colleague has sent a mail to the whole staff at my company with the picture broadcasted by Jörg Stappert from harmon.ie about the results of the voting for the Top 25 SharePoint Community Influencers: https://twitter.com/JStappert/status/299429178309218304/photo/1
A big hand for all the voters! I am honored to see my name with some of the best SharePoint specialists. Thank you for this!
See this blog-post for some background: http://harmon.ie/blog/harmonie%E2%80%99s-%E2%80%98top-25-european-sharepoint-influencers%E2%80%99-awards-cap-european-sharepoint-conference
In the Software boundaries and limits for SharePoint 2013 article in Technet, Microsoft has added a new limit for the number of content databases (http://technet.microsoft.com/en-us/library/cc262787(v=office.15)#ContentDB). Beginning with SharePoint 2013 there is a limit of 500 content databases per farm as a supported limit.
But remember, when working with these number so content databases, the complete infrastructure has to be set up properly.
I am actually doing some tests with SharePoint 2013 and its new improvements. Therefore I have setup a Windows Server 2012 with SharePoint Server 2013 and Office 2013 on one single machine. That’s sufficient to get an overview.
When creating a new document for a document library, Word 2013 opens and shows a banner stating that the document was opened in Protected View and editing is disabled.
This is because of the security settings in the Trust Center. To change this behavior open the Trust Center Settings, switch to the Protected View section and uncheck “Enable Protected View for files located in potentially unsafe locations”.
The next time you create a new document in a library, the new document is opened in edit mode.
As in SharePoint 2010 we can install Language Packs and use more than one language at the frontend. In the Site Settings we also find the Language Settings, where we can select all the languages our site should use.
But when you try to switch to another language in the welcome control, as we did it in SharePoint 2010, you will miss this menu item.
Switching the language in SharePoint 2013 is moved to the language settings of the browser. So, to switch the language, open Internet Options of the Internet Explorer and move the language of your choice to the beginning.
(This screenshot is taken from IE 10).
I do not know if I like this change. To test multilingual solutions, the option to switch several languages as in SharePoint 2010 was better, because language switching was easier.