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!