I’ve configured Forms Based Authentication (FBA) in SharePoint on several occasions – from 2007 right through to 2013, but until now I have never discovered a life-saving tool that Steve Peschka has written called Forms Based Authentication Configuration Manager (FBA Configuration Manager for SharePoint 2013) available on his TechNet Blog Share-n-dipity.
I’ve been there at least once or twice and I’m sure others have as well – where we’re happily modifying the web.config on half-a-dozen or more servers and as Steve so elegantly describes it, we “fat finger some random part of a web.config change” causing complete devastation to the running of SharePoint and to your progress. Well not any more my sysadmin friends, not any more not with this tool. It allows you to edit the connection string, people picker wildcard, membership provider, role provider details within the web.config for a specific web application. It then creates a backup copy and updates the web.config across all the servers in your farm through a timer job which is a really neat trick.
Having done this now on several occasions I thought I was pretty confident flying through the steps necessary within an hour or so…the occasional error would sneak in and then I would spend as long again troubleshooting the configuration. Steve’s Forms Based Authentication Configuration Manager has now completely removed the chances of any errors sneaking in and will make me even quicker configuring FBA in SharePoint. Thank you, Steve!
Since our Office 365 tenant was upgraded we’ve been experiencing difficulties with our users signing into Lync 2013. When these users tried to sign in, the Lync 2013 client returned an error saying it could not communicate with the server. The users received the following error.
“The server is temporarily unavailable.”
Background
Firstly our IT guy raised this issue with Office 365 through a support ticket some months ago when we started experiencing this issue. There was some back and forth communication however no solution was ever found. As far as I know, the issue is still open.
A few months passed and I was getting more and more frustrated that I wasn’t able to communicate with my team using Lync so I decided to spend some time and see if I could find a solution myself.
Here is some other background information about our configuration…
Domain joined machines using Office 2010 were ok
Mobile clients were fine
All users are part of a Windows 2008 R2 Active Directory domain that is not connected to Office 365 through ADFS or DirSync
User accounts experiencing the issue have spaces in their account name (Joe Bloggs)
The Office 365 DNS records are set up correctly – even broke out fiddler and checked my Lync client was reaching it’s end-points correctly which they were
Our internal domain is using an unresolvable .local address
After reading countless forum posts I noticed many others were reporting similar issues and the issue seemed quite widespread.
So after some research, I read that Microsoft was aware of the bug and did not expect it to be resolved until September time. Others were saying that it worked with users whose machines were not joined to an Active Directory domain. This leads me to think about try using a local account and there it is folks – my solution!
This is less of a solution but more of a workaround whilst Microsoft fix this issue once and for all!
Kill the “lync.exe” process (use Task Manager to end the process)
Create a new local user account on the computer (lusrmgr.msc)
Add this account to the Administrators security group
Navigate to the Program Files directory for Lync 2013 (C:\Program Files\Microsoft Office 15\root\office15\)
Whilst holding the SHIFT key down, right click on the “lync.exe” application and select “Run as different user”
Enter the username and password of the account that was just created
Lync 2013 should open and launch the “New user configuration” window
Sign in to Lync 2013 with your Office 365 username and password
The Lync 2013 client should now happily work
I should highlight that some features such as creating a Lync meeting through Outlook might not work due to the processes running as different user accounts. Try it out for yourself and see.
Fingers crossed Microsoft fix this issue pretty soon!
Ok, so this has bothered me for some time – until now, there has been standalone OneDrive for Business SkyDrive Pro client. Users have had to install Office 2013 to experience the new way of synchronising files with SharePoint.
The reason it has bothered me is that it is such a limitation to require the client to be installed in this way. For most organisations, it is just not feasible to install the latest and greatest software from day one due to budgets and wider IT constraints, resources and policies where software has to be tested, licensed and patched for example.
Let’s put that aside now as I’m really happy to see that Microsoft released a standalone installer for the OneDrive for Business SkyDrive Pro client earlier this week.
The client can also be installed alongside previous versions of Office and can be used to synchronise libraries from SharePoint 2010, SharePoint 2013 and SharePoint Online in Office 365.
If you need to check what version of SharePoint server your Office 365 tenant is running especially during the Office 365 and SharePoint Online service upgrade (aside from checking through the Admin Portal via https://portal.microsoftonline.com) then you can add the following /_vti_pvt/service.cnf to the end of your SharePoint site – as shown below.
The page will output two lines of text from which we can determine the version of the SharePoint servers. If the second row starts with 14 then you are running SharePoint 2010, if it starts with 15 then you are running SharePoint 2013.
After the service upgrade, you may be running SharePoint 2010 on SharePoint 2013 servers (technically known as 14 mode) until you upgrade your site collections to SharePoint 2013 (15 mode).
Update: July 2015 Some readers have kindly brought to my attention that after reading this post, they were concerned as to data security. Having read this post back, some two years on, I can see how some misunderstanding can be made from this post, so I’ve updated the article to reflect this. Finally, the disclaimer on this site has always suggested you validate the information with secondary sources. Microsoft also publishes information around how they protect and secure data in Office 365 on their Office 365 Trust Center site – please use this for any concerns around data protection. Additional information: Partner admin centre
At the time of writing this post, I was working for a “Microsoft Cloud Accelerate” partner. As a result of this, certain user accounts within our own Office 365 tenant were able to provide support to our customers, they would need to explicitly agree to the partner providing ‘delegated administration’ to their Office 365 tenant.
Delegated administration allows selected users to perform ‘delegated administration’ functions to Office 365 tenants (those that have allowed this) using their own credentials. This could be creating support tickets, managing users accounts and resetting passwords to configuring their services – it is also possible to support customers with SharePoint Online.
All of this of course, from setting up ‘delegated administration’ through to supporting customers with this function should be always be agreed and authorised with the customer. A key point to make clear with your customers is that by establishing the ‘delegated administration’ trust, the partner has access to provide ‘delegated administration’ to Office 365 services, subscriptions and SharePoint Online for example in their Office 365 tenant.
Create a delegated administration offer for your customers
To create a delegated administration offer for your customers you must do the following:
Click on the link “Send delegated administration offers” link.
Copy the information that appears in the window and sends this offer on to your customer(s). The offer isn’t customer-specific so you can reuse this offer for multiple customers.
The customer must then click on the link they receive and proceed to authorise you the partner as a delegated administrator of their Office 365 tenant. You will then receive an email confirming they have configured delegated administration.
In order for users within the partner organisation to perform delegated administration, they must be given administrative access to companies you support.
To do assign users with the permission they need you must complete the following:
Navigate to the “Users and groups” page.
Find the user you wish to give this permission to and select “Edit”.
From the “Settings” page scroll down to the “Assign administrative access to companies you support” and select “Yes”. This will then give the user access to the “Partner overview” page.
Then choose the appropriate role, and then click “Save”. The full administration role has the same privileges as the global admin role for the companies you support. The limited administration role has the same privileges as the password admin role for the companies you support.
Performing delegated administration
To do administer a customers Office 365 tenant you must use the “User and domain lookup tool” that is available on the “Partners” tab. Here you can enter your customer’s information it will bring back information about the tenant such as the subscription type and contact information. This page also displays three links to “Administer on behalf of”, “Create service requests” and “Show all administrators”. The “Administer on behalf of” link will then takes you to the “Office 365 admin centre” where you can manage and administer their tenant.
A quick post here to share a new feature in SharePoint 2013 that enables you to easily embed code such as javascript and CSS into the content area of a web part page for example.
Previously we did this by editing the page source or by creating lots of text files and linked them using the “Content Link” parameter in “Content Editor Web Parts (CEWP’s)”. Now we can easily embed code on a content page where SharePoint places it is in a lovely dedicated snippet section that is only visible when you edit the page.
When you add any javascript SharePoint converts the “edit snippet” link as shown above to a web part where you then edit the content much like the “Content Editor Web Part”.
I’ve been exploring SharePoint 2013 in recent days and noticed that the ‘Sign in as Different User’ option or action from the welcome control (user menu) seems to have been removed or forgotten from the user interface in this build.
For someone who works with SharePoint as I do, any kind of administration, developing or testing that requires you to sign in as another you will now become convoluted from the previous version and is somewhat frustrating and annoying. Others such as Nick Grattan have discussed this issue and possible workarounds.
Of all the workarounds currently available such as browsing to the closeConnection page directly, modifying the welcome control and adding the control back (I do not recommend this approach), creating a javascript bookmark, embedding jQuery into the master page to insert the option back in the menu and lastly launching the browser with the RunAs option my preference will remain to browse directly to the closeConnection page:
This one’s quick. There are a couple of ways to find out your SQL server version. Firstly the version is listed within the Object Explorer in the Microsoft SQL Server Management Studio. The second option which provides more detailed information is to run the following query.
select @@version
The version information is returned in the query results section at the bottom. Both examples of obtaining the SQL server version are shown in the image below.
I was asked to review a client environment yesterday to find out why the links in their top navigation bar were displaying for users that did not have permission to the particular sites.
Creating sites
It turns out that when sites were being created by the client on SharePoint Foundation 2010 they were being created without the ‘include on the top navigation bar’ check box ticked. As a result, the link was then not automatically added to the top navigation bar but instead later manually added and so was not security trimmed link.
It was then after removing permissions to the various sites that it became clear that users were able to see the top navigation bar link to the sites even though they did not have access.
Obviously, there are situations when users don’t have permissions to a site and you don’t want them to see that the site even exists. An example of this might be in an extranet scenario when you have third parties accessing project sites and you don’t want those third parties seeing the names of other project sites that may exist let alone the content…so how do we prevent this?
Identifying security trimmed links
By reviewing the URLs of the links in the top navigation bar I was able to identify whether the links were security trimmed or not. If the field for the URL is disabled then the link is security trimmed and most probably created when as the site was created.
Adding new security trimmed links
After identifying the problem, I then had to make the existing links security trimmed. I did this in two stages. The first was to make a note of the position of the link that needed to be replaced. I then deleted it from the top navigation bar using the ‘Top Link Bar’ site settings page (_layouts/topnav.aspx). The second stage was then to create the new security trimmed link by using the PowerShell code below.
Modify the $SPWeb and @(“Site Name”, “/sitename/default.aspx”) arguments as required and run the code for each of the top navigation bar links that need to be security trimmed. Remember the old link will need to be removed and the new one ordered as required.
Conclusion
It appears SharePoint, specifically SharePoint Foundation 2010 only honours security trimmed links in the top navigation when the links are created automatically as opposed to being created manually.
Note: this post specifically targets SharePoint 2010 Foundation which does not include the extended navigation that is included as part of the Publishing feature.
On many occasion, I have been to conferences and on training where the presenter has done a demonstration and used a screen magnifying utility to enlarge part of the display. There are many utilities available that provide this functionality and are typically included with the accessibility option of most operating systems.
Having asked many a presenter what they were used to magnify the screen, most pointed in the direction the Sysinternals utility ZoomIt which I have since used. More increasingly I am presenting and doing demonstrations on my Mac which leaves without such as useful utility.
After a short time reviewing various Apps available, I decided on Zoom It for Mac for a small price of £0.69 in the Mac App store. It sits nicely in the toolbar and allows you to customise the loupe size, zoom and shape through various key shortcuts or from the toolbar menu.
Enhance your demonstrations and use a utility like either of the magnifying utilities I’ve mentioned – I sure am!
This morning I was trying to create a new style in the itemstyle.xsl stylesheet to use within the content query web part (CQWP). I needed a custom style to display a list of announcements, some of which had content and others didn’t and this style was to improve this output.
The problem is that the ‘Body’ column of an announcement or more importantly the ‘rich text’ field type is never really empty. Even when the column genuinely empty and has no rich text content, a hidden HTML element (a div) exists and acts as a wrapper for any content. As a result, if you try and use a typical ‘if equals null’ statement to hide the rich text column it won’t work because of this hidden element.
Examples
An empty rich text column on SharePoint 2010 always has 37 characters as shown below.
With SharePoint 2007 the rich text column has 65 characters when empty, again as shown below.
Solution
The solution, in the end, was to use the string-length function to determine if the rich text column was longer than the standard 37 characters on SharePoint 2010 as identified above.
Quite a common requirement for implementations of SharePoint that I am involved in is to create new managed paths for a given web application.
While it is a simple task to perform via Central Administration, I inevitably turn to PowerShell to achieve this so that I can then include it as part of larger configuration or deployment scripts.
To get a list of all the managed paths for a given web application we use the Get-SPManagedPath cmdlet as shown below.
Creating a new explicit path
Explicit managed paths only allow one site collection to be created at a specific path. An example of this is the root site collection of a web application which has an explicit managed path of “/” (https://sharepoint.jcallaghan.com).
To add a new explicit managed path to a web application we use the New-SPManagedPath cmdlet and include the -Explicit parameter.
Adding a wildcard managed path
Wildcard managed paths allow one or more site collections to exist at a specified path. This is the same as the default ‘sites’ managed path that we should all be familiar with (https://sharepoint.jcallaghan.com/sites/projectxyz).
To add a wildcard managed path we run the command as we did for an explicit managed path however we don’t include the -Explicit parameter.
Removing an existing managed path
There may be times when you need to remove managed paths. This can be done by running the Remove-SPManagedPath cmdlet and specifying the name of the managed path to be removed and what web application to remove it from. When removing a managed path you will be prompted to confirm the removal action – this can be silenced by adding -confirm:$false to the command.
Conclusion
Using the SPManagedPath nouns in PowerShell we can get a list of existing managed paths, create explicit or wildcard managed paths and also remove existing managed paths for a given web application.