Sharepoint 2010 - Hide the Quick Launch Navigation on a page

One possible way to hide the Quick Launch panel on a page is to modify the page layout for example of the default.aspx page.

<style type="text/css">

#LeftNavigationAreaCell { display: none !important; }

</style>

Another method for hiding the Quick Launch is to add a Content Editor Web Part to the page and add the following code to the webpart.

<style type="text/css">

/*--Hide Quick Launch Panel--*/

#s4-leftpanel{

display:none

}

.s4-ca{

margin-left:0px

}

</style>

The last method is to add the code to the Masterpage for the site (just before the closing head tag) and this will eliminate any extra space in the top left area. 

Passed the 70-668 PRO: Microsoft SharePoint 2010, Administrator Exam

I took this exam today and passed, I think it was definitely harder than the 70-667 exam, 65 questions in all, 16 break out portions that were based on a reusable customer requirements scenarios. There were about 10 questions that you had a list of items in the left box you had to drag the correct # of items and put them in the correct order.

A few I remember with the select-able steps - just basic idea here I don't remember much!
1. Configure a content deployment path. Choices were things like create a deployment path on server 1 or server 2, allow content deployment, create a quick deployment job, create a content deployment job etc.

2. You must create a new site at the top level of a site collection based on a saved template. Choices were save site as a template, import stp file and activate, save site template, import WSP file, etc.

3. They asked for you to add Excel and Visio services to your farm, requirements were best performance and redundancy. Choices were install a new app server, install Sharepoint 2010 into a SQL Cluster, install the enterprise version of Sharepoint on all servers using the /Complete option and then a configuration list in one box. I really hated the way this question was worded, probably missed it.

4. One question asked to configure servers for sandbox solutions, must as isolated as possible and redundant,  displayed a farm with 3 WFE's and one index server. Choices were stop sandbox service on WFE 01 & 02, stop sandbox service on WFE 03, start sandbox service on WFE01 & 02, start sandbox service on WFE03, start sandbox service on WFE03 & start sandbox service on QS01, stop sandbox service on WFE03 & start sandbox service on QS01

Things to be proficient on, when to use each type of authentication type, kerberos, claims, forms, integrated. How many servers, web apps, site colls, based on a given customer scenario. Different upgrade types and when to use each. Search - understand query server, query mirroring, crawl components, index partitions, how to isolate each part of search within your farm, authoritative pages, search federation etc. a couple of Infopath forms questions, several backup questions on perform a backup, granular backup, backup-spsite, backup-spfarm powershell cmdlets. A few BCS questions and a few talking about secure store service application, moving 2007 SSO farms into 2010. Memorize all of the web application general settings, all of the backup settings in CA and all the monitoring settings like diagnostic, trace log, web analytics, etc.

Upgrade Sharepoint 2007 Shared Service Provider(s) to Sharepoint 2010

Working on a MOSS upgrade project I recently discovered the only complete upgrade method for the MOSS Shared Service Providers is an In Place Upgrade. The In Place Upgrade method will actually take the original SSP(s) and map them over into the new 2010 database architecture i.e. BDC database, Search Service Admin database, Search Service Gatherer database, Taxonomy database and User Profile database.

The Database Attach upgrade method can be used on a MOSS SSP however, only the User Profile data will be upgraded into Sharepoint 2010 User Profile database. All of the remaining items from the SSP will have to be manually created/configured using 2010 Service Applications.

One or more field types are not installed properly. Go to the list settings page to delete these fields.0x81020014

Recently came across this error message after migrating a site from Sharepoint 2007 to Sharepoint 2010. Apparently it is an issue where the relationships list is not updated when migrating a site.

The Relationships List can be found at http://(yoursiteurl)/Relationships%20List/allitems.aspx

As the site collection administrator deactivate the SharePoint Server Publishing Infrastructure feature under Site Settings for the site collection that has the issue. Then delete the Relationships List - http://(yoursiteurl)/Relationships%20List/allitems.aspx.

Re-activate the SharePoint Server Publishing Infrastructure feature and the Relationships List will be recreated, this will correct the problem.

Update Sharepoint Domain Group Name attribute after migrate

If you migrate a Sharepoint Farm into a new domain and use the STSADM -o migrategroup command it does not update the name attribute. The LoginName attribute will be correctly updated. The following Powershell script was written to address this.


The script only updates the display name of the groups, does not alter any security permissions and only looks for Domain Groups with "OLDDOMAINNAME\" in the name attribute.

The script copies the Domain Group LoginName attribute and replaces the name attribute with that value.

The script accepts a URL parameter and will get the web application for the URL you pass in and iterate all the sites in that web application.


[Reflection.Assembly]::Load("Microsoft.SharePoint, Version=12.0.0.0, Culture=Neutral, PublicKeyToken=71e9bce111e9429c")
#enter a site URL
$siteUrl = Read-Host "Enter Site URL"
$rootSite = New-Object Microsoft.SharePoint.SPSite($siteUrl)
# Get the web application for that site URL
$spWebApp = $rootSite.WebApplication
# Iterate the sites for the web application
foreach($site in $spWebApp.Sites)
    {
# Iterate the users/groups for that site
$group = $site.RootWeb.SiteUsers
foreach ($grp in $group)
{
# Ensure the item is a domain group
if($grp.IsDomainGroup -eq "True")
{
$groupname = $grp.name
if($groupname.Contains("OLDDOMAINNAME\"))
{
$grp.name = $grp.LoginName
$grp.Update()
$outputText = "$spaceBuffer$BUFFER_CHARS<Group>" + $grp.LoginName + "   --Updated"
Write-Output $outputText
}
}
}
}

Kerberos on Windows Server 2003 and Sharepoint 2007

Windows 2003 defaults to using UDP protocol for Kerberos. In our traces we were getting Kerberos errors because the packets were too small. Seems TCP packets are larger, so we had to modify the registry to force windows 2003 to send Kerberos messages through TCP. 


Another trace and the issues were resolved, prior to this setting we were experiencing unpredictable prompting issues with Kerberos enabled sites in Sharepoint 2007.