FireFox Prompting for Credential for Intranet Sites

FireFox Prompting for Credentials for Intranet Sites

I've stumbled upon an issue that FireFox Users in a Corporate Environment are being prompted for Authentication to Internal sites.  Essentially what's happening is that the browser isn't passing the User Credentials for Internal sites and causing users to log into each internal site they visit. 

It looks like FireFox has added some parameters to allow for User Credentials to be passed to specifically listed sites.  I'm currently using version 15.0.1. 

Here are the steps I used to stop the many prompts:

• Open FireFox
• Type "about:config" in the Address Bar
• Make sure you read the warning message
• In the Search, type "network.negotiate"
•  Double click network.negotiate-auth.delegation-uris
• As a single line and separated my commas, enter the URL's of the sites that you wish to pass Credentials for
• http://intranet.contoso.com, http://accounting.contoso.com

If you're using Host Headers, you may need update another parameter: network.automatica-ntlm-auth.trusted-uris

• Update network.automatica-ntlm-auth.trusted-uris by listing the Domain Suffix for your internal sites:
• .contoso.com, litware.com

If you're using Kerberos Authentication and Host Headers you may want to update another parameter: network.negotiate-auth.trusted-uris

• Update network.negotiate-auth.trusted-uris by listing the Domain Suffix for your internal sites
• .contoso.com, litware.com 

Hopefully this will eliminate multiple prompts for credentials for FireFox Users working in a Corporate environment.

Enjoy!

Rename a Site Collection

Occasionally users want their Site Collection renamed and the URL updated. It's a very reasonable request and pretty simple if we were dealing with a non-SharePoint website.  Since we can't rename a site collection through the UI we have to get a little more creative.

 

  

The Problem:

• Need to change the name of the Site Collection
• Need the URL to update with the name change
• No renaming option in Central Administration
• No renaming option in Manage Content and Structure

This isn't a single step process, but overall the process is pretty simple.   

 

Prerequisites:

• Access to Central Administration
• Destination Path to Export the Site Collection as a .CMP File
• Name of Current Site Collection
• Name of New Site Collection
• Users who decide on a site name and then change their mind

 

The reason why we have to Export the Site Collection is so there won't be duplicate GUID's for what is actually a different Site Collections.  You can't have 2 Site Collections with the same ID's in 1 Farm, as it would *literally rip a hole in the space/time continuum.

 

 

The Solution:

 

 

We'll be Exporting the current Site Collection to a File and then restoring it under a different name.

 

1. Open Central Administration
2. Select Backup and Restore
3. Granular Backup > Export a Site or List
4. Under Site Collection, Select the Site Collection to Export
• No reason to select site or list since we're exporting the entire site collection
• example http://intranet/sites/old_and_broke
5. File Location > Path + File name for the Export:  C:\exports\old_and_broke.cmp
6. Select Export Full Security, but it can be deceiving and the Full Security doesn't come over well
• I recommend you verify the security after restoring, as this process will create new SharePoint Site groups
7. Export All Versions
8. Click Start Export 

After a few minutes, which will vary depending your server, size of the site collection and the SharePoint Gods, the export will be complete. 

 

 

Renaming and Restoring the Site Collection using PowerShell

 

**There is an extremely complicated PowerShell command that we'll use to restore the site collection and rename it at the same time.

 

 Restore-SPSite http://intranet/sites/new_hotness -Path C:\exports\old_and_broke.cmp -Force

-DatabaseServer IntranetDBServer -DatabaseName WSS_Content_Intranet 

 

This line of PowerShell will restore the site collection under a new URL and to a specific Content Database.

 

 

Option #2 for renaming and restoring

 

There is also a 2nd option for restoring, if you already have an existing site collection you want to overwrite. 

Prerequisite:  The new site site collection with the new name must already exist.

 

Import-SPWeb http://intranet/sites/new_hotness –Path C:\exports\old_and_broke.cmp 

 

This wonderful line restores the site collection over top of an existing site collection. 

 

 

Option #3 for renaming and restoring

 

You can create a site collection, based on a site template with PowerShell and then restore overtop of that.

 

New-SPWeb http://intranet/sites/new_hotness -Template "STS#0"

Import-SPWeb http://intranet/sites/new_hotness –Path C:\exports\old_and_broke.cmp 

 

 

Enjoy!

 

 

 

*No actual evidence of space ripping or even time ripping.

**Not actually complicated or extreme.

View SharePoint Content Database Growth with Powershell

Recently I've been asked to move some sites and site collections back and forth between the Production and Pre-Production environments for Testing, Development and even for a quick recovery option if something is broken by a user. 

I had a concern: "Do we I have enough room in the non-Production Enviroments for theses moves?".



I have a script to be more proactive and a little less reactive to potential disk space issues. Here's the simple Powershell Script and a little bit of Technical Math for presenting easy to read results.



1.  Add-PsSnapin Microsoft.SharePoint.PowerShell
2.  $date = ( get-date ).ToString('yyyyMMdd')
3.  $file = New-Item -type file "c:\DBSizes\$date-dbsize.csv"
4.  Get-SPDatabase | Sort-Object disksizerequired -desc | Select-Object Name, WebApplication, CurrentSiteCount, @{Label ="Size in MB"; Expression = {$_.disksizerequired/1024/1024}}
Export-CSV -path $file



Basically this script will pull the all the sizing informatino of the databases in the SharePoint Farm. It will include all Service and Content DB's. This will also export the results to a CSV and then formatting the size in MB rather that just Bytes.



I'm going to use this script as a Windows Scheduled Task and execute it monthly. The Task is going to run as the farm account and will pull sizing information from all Databases in the Farm and drop it in in a Folder called "DBSizes".  Nothing tremendously ground breaking here, just a really simple way to see what's going on in your environment and where growth has occurred. 


Enjoy!

Find a users in SharePoint groups with PowerShell

I've been spending some time investigating the Get-SPUser and Set-SPUser commandlets.  I'll be the first to say that SharePoint 2010 and Powershell is a GREAT way to manage a SharePoint Farm. 

The Problem

I was trying to figure out a simple way to get "Setup Like" information for an existing user, so that we could grant permissions for new users.

It would turn out that this is a pretty simple task. 

get-spuser -identity contoso\bgates -web http://contoso/sites/sitecollection | select groups

Groups
------
{Contoso Owners}

Turns out, contoso\bgates is in the "Contoso Owners" Group (didn't see that one coming).  Well since contoso\sbalmer needs to be setup like contoso\bgates we need to run another line of PowerShell

set-spuser -identity contoso\sbalmer -web http://contoso/sites/sitecollection -group 'Contoso Owner'

Update Site collection user without the User Profile Service

Updating Site Collection Users - Without a User Profile Service

Recently I ran into users, who were added to a Site Collection, but found they had incorrect information in Active Directory at the time of addition.  Active Directory had been updated since, but the Site Collection User had not been.

Problem - Update a Site Collection User that had incorrect information, listed in Active Directory, when added to the Site Collection.

It was a simple mistake where a Display Name had been was listed incorrectly. 

The Script

Here is an extremely complex PowerShell command to fix this issue:

Set-SPUser -Identity 'contoso\sbalmer' -DisplayName 'Balmer, Steve' -Web http://contoso/sites/sitecollection

The basics of this line of extremely complex powershell is broken down to the following:

Commandlet - Set-SPUser
Identity - 'Domain\UserName'
DisplayName 'LastName, FirstName'
Web - The site collection where the user needs to be updated.

The Next Question

This made me ask another question:  How do we refresh all attributes from Active Directory for a User? 

I found this to be even more complex than the first line of PowerShell from above. 

Set-SPUser -Identity 'contoso\sbalmer' -SyncFromAd -Web http://contoso/sites/sitecollection

This will simply update the user from Active Directory, for the listed site collection. 

This will also resolve the issue if a user has the same Domain Account ID as a former employee.  This is probably rare, unless the site was migrated from previous environments from years past. 


Enjoy!

Resize SharePoint User Profile Pictures

If you don't host your Employee Directory Photos in Active Directory (which I've found to be pretty common), and you're using SharePoint 2010 User Profiles, you've probably done something in Forefront Synchronization Service Manager to import the Photos.  Possibly something custom or really cool that I've never even heard of.  Regardless of how you get the pictures into SharePoint, you may have a new problem:  Picture Sizing Issues.


Here's some simple Powershell to Resize those User Profile Pictures that you can run from the SharePoint 2010 Management Shell. 


Update-SPProfilePhotoStore –MySiteHostLocation “http://YourMySiteHost/”

If you want to run it from regular old Powershell it becomes a *massive 2 line script. 

Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue

Update-SPProfilePhotoStore –MySiteHostLocation “http://YourMySiteHost/”


What's Next?

How do we take advantage of this amazing automation you ask?  Well, for simplicity, you could save the regular option or *massive option as a "resizeUPSPhotos.ps1" and run the "resizeUPSPhotos.ps1" in Task Scheduler (or whatever you use as a Job Execution Server). 

*Note: Not actually "massive" since it's only 2 lines.



You should take into consideration the Task scheduling so that it executes after the User Profile Syncronization completes.  This could vary depending on the size of your organization and time it takes to complete the syncronization.  Much like the first Full Syncronization takes to import, the first time your resize the photos, it will also be slow.   

A Farm Administrator will be needed to run the job.  It's possible that there might be a less permission role that could be used to resize the photos, but I haven't gone that deep into investigating it.



How do I import from another source?

If you're looking to Import Employee Pictures, from a source other than the Active Directory Thumbnail Attribute, here's a great article to do so, by Chaitu Madala - http://www.chaitumadala.com/2010/05/setting-up-pictureurl-user-profile.html

Adding a Content Database to a farm with different patch levels.

Attaching and Upgrading a SharePoint 2010 Content Database

I was recently tasked with the challenge of taking a content database from a SharePoint 2010 Farm, pre-Service Pack 1 and attaching it to a Post-Service Pack 1 SharePoit 2010 Farm.  Seems like a pretty simple task.  We can do this a number of ways, including Central Administration, STSADM or PowerShell. 

I personaly prefer Powershell for simplicity and how many options we gain by using it.  Here's a breakdown of some options for attaching a Content Database, granting access to domain account previously configured as Managed Accounts in your Farm and upgrading the Content Database. 

The following below assumes that Content Database has already been attached in SQL by our Database Administrator friends, and now we need to make use of it in SharePoint.  *FYI - DBA's do not like spaces in Database Names,  so when you create them, don't use names with spaces.*



Add Content DB:

Mount-SPContentDatabase "Content_Database_A" -Database Server "DBServerName"-WebApplication http://webappA



Here's a link for reference - http://technet.microsoft.com/en-us/library/cc825314.aspx
It's hardly a complicated or lengthy script, so you either save it as "AddContentDB.ps1" and run it or just paste it into the SharePoint 2010 Management Shell window. 



Attach and Upgrade a Content Database.


New Challenge - Attach a Content Database from a Farm with lower patch level. and then upgrade it once it's attached.  To solve this challenge we'll need to upgrade the database after attaching it.  Again our friend Mr. PowerShell will be able to help us.  


Mount-SPContentDatabase "Content_Database_A" -Database Server "DBServerName"-WebApplication http://webappA
Get-SPContentDatabase | ?{$_.NeedsUpgrade –eq $true} | Upgrade-SPContentDatabase -confirm

This will do 2 things here, with a prompt before starting the 2nd thing. 
#1)  This will Attach the Content Database
#2)  This will look for any content databases that need upgrading and prompt you to upgrade 1 or all of them. 



Attach a Content Database, Grant a  Domain Account access and Upgrade the Content Database.


Yet another challenge.  Attach a Content Database, grant access a Domain Account access (ideally also a ManagedAccount in your Farm) and upgrade the database after it's attached.


Mount-SPContentDatabase "Content_Database_A" -Database Server "DBServerName"-WebApplication http://webappA
$webapp = GetSPWebApplication "http://webappA"
$webapp.GrantAccessToProcessIdentity("Domain\AcountNameA")
Get-SPContentDatabase | ?{$_.NeedsUpgrade –eq $true} | Upgrade-SPContentDatabase -confirm


This probably isn't a very common situation.  But if you're running Office Web Apps as a Domain Account, different from your Web Application Account, you'll need to grant the OWA account access to the Content Database.  I'm creating a topic for another post, but something to note, the Office Web Apps Cache is part of each Content Database so the account will need access. 

Installing SharePoint on a "non-standard" SQL Port

Attempting to install SharePoint on a "non-stardard" port can be a challenge.  Typically a Database Administrator will not run SQL on the standard port for security concerns.  Additionally, you might be attempting to install SharePoint on a Cluster and attempting to connect to the Cluster Port where your instance of SQL is being hosted.  

The "non-standard port" creates a challenge for SharePoint Administrators and the SharePoint Installation.  The SharePoint installation is looking for SQL Server on the Standard Port (1433).

An option that I've used and found to be very effective is the creation of a SQL Server Alias on each server in the farm.  It's never bad, in my opinion to alias your SQL Server connection.  You never know when this will be helpful in the future, specifically in the case of a database migration or hardware refresh.



Steps to create a SQL Server Alias:

1. Open SQL Server Client Network Utility.  (I believe this tool is native to Server 2003, 2008 and 2008 R2).
2. Click on the Alias tab
3. Click Add
• Server Alias:  "Enter the Alias information (eg. "SPDatabase")
• Network Libraries:  TCP/IP
• Server Name:  "Enter the name of the SQL Server you where the Databes will be hosted"
• Dynamically Determine Port:  "Uncheck to enter a specific port, or leaved checked to dynamically determine port

Notes:  If you leave "Dynamically determine port" checked, your Database Administrators can do some magic on their side to forward requests from a specific account to a specific port. 

You'll need to recreate these steps on all the servers in the farm.

SharePoint 2010 - Uniquely Secured Content

A very nice feature from SharePoint 2010 is the visibility into site content. I can't even count the number of times I've received the question from users "I gave them access to my site but they still can't see the list!".

There's a simple explanation for this. Inheritance is broken and "The List" has unique permissions. Unfortunately the Technology Team, more often than not, needed to get involved to communicate to with the user.  For the more seasoned business users, the next question would be "So what do they have access to?".

Great question and a great answer for SharePoint 2010 to solve this problem?

Under Site Permissions, you have the option to see content with Unique Permissions.  Click on the link "Show me uniquely secured content".



Show me uniquely secured content



Microsoft has really been listening to our Admistrative Challenges and gave a great and simple way to continue to empower the users.  Once clicking on the link we can see what's uniquely secured.  In the screen shot below, "Site Collection Images" and "Style Library" have unique permissions and are not inheriting from the site. 

Docs and Test contain item level permission in side the libraries which is defined with "Lists that may contain items with unique permissions".  It's a little bit misleading because Docs is a document library, but let's focus on what's important:  We have better visability into our busines content and can better share those insites with our clients. 

The Search Service is not able to connect to the machine that hosts the administration component.

I've seen many posts about people who are trying to deploy the search service and are receiving this message. Unfortunately most of the solutions I've see say "Rebuild the farm", "Delete the service and start over" or some other doom and gloom scenario. I've found something that seems to be consistently missed - PERMISSIONS

When the Search Administration Web Service for Search Service Application component is created, it is only granted access as Local Farm - Full Control. Basically if you're not creating the Search Service as the Farm Account, you will see this message.

Never fear! There is a very easy fix. Give your installation account permissions to the Search Administration Web Service for Search Service Application.

This will prevent you from having to delete the service, rebuild your farm and lose your sanity.