Thursday 3 September 2015

What is Central Administration, WFE and Application Server in SharePoint?


Central Administration (CA)
  • Central Administration is the management tool for your whole farm.
  • When you install and configure SharePoint Products and Features (SharePoint Foundation, or SharePoint Server etc.) on any application server, it automatically provisions a central administration site on that server.
  • Typically Central Administration is hosted on Application server. When the service “Central Administration” is running on any application server, that server hosts site for Central administration for the whole farm.
  • CA is kept on application server as it is not a high traffic site and won't affect performance of the application server.
  • It also allows you to extract a level of security by not putting it on a web front end, which could be accessed via a load balancer, instead it's on server that's behind the scenes that less users would even know about.
  • CA is an admin only site that has the potential to completely destroy your entire farm if misused or hacked. In many farms, particularly Internet/Extranet farms, the WFEs are exposed to the internet and are thus subject to being hacked. If CA isn't installed on a WFE, it eliminates the potential that a hacker will gain access to it.
  • On the server that is running SharePoint Products, click Start, point to Administrative Tools, and then click SharePoint Central Administration.
     
    Web Front End Servers (WFE server)
  •  A “Web Front End” (WFE) is a server where only “WSS/SharePoint Foundation Web Application” service is running from the below table “Server services”.
  • A WFE handles web requests from users and hosts all SharePoint files on the disk.
  • The assemblies are deployed to the global assembly cache (GAC) of every front-end web server in the farm and run with full trust.
  • A WFE has all the web applications (in IIS), Assembly in GAC and SharePoint related files in 12/14/15 hive.
  • You can have more than one WFE for load balancing (just install a secondary WFE in the Farm).

 Application Server (App server)
  •  An “Application Server” is a server that is capable of running any of the services from table below apart from the “WSS/SharePoint Foundation Web Application” service.
  • Application server hosts services such as: Excel, Search etc. and you can have one or more application servers in the farm for scalability and balancing.
  • You could split Excel and Search on two different servers (application) in the farm.
  • SharePoint will not replicate contents of WSP on app server as the “WSS/SharePoint Foundation Web Application” service is turned off there.

Server Services (MOSS version)

Server Service
Purpose 
Windows SharePoint Services Web Application (often referred to as 'Web Server' or 'WFE')
This service is responsible for serving the HTML to clients and routing requests to other services in the farm.
This service can exist on multiple servers. Those servers are called as WFE servers. 
Office SharePoint Server Search in Query Mode (often referred to as 'Query Server')
This service is responsible for executing search queries against a locally stored copy of the index
Yes, this role can exist on multiple servers.
Office SharePoint Server Search in Index Mode (often referred to as 'Index Server') 
This service is responsible for indexing all of the configured content sources, creating an index and propagating it to every Query server in the farm
Windows SharePoint Services Search
This service is basically a slimmed down version of the Office SharePoint Server Search service which combines both the Query and Index roles into a single service.
If you have more than one instance of this service in a farm, it will simply do the same thing as the other servers.
Excel Calculation Services
This service is responsible for performing calculations on Excel workbooks that are stored in the content databases.
Many instances of this service can exist on the same farm.
Document Conversions Load Balancer Service 
This service balances document conversion requests from across the server farm.
An application server can only have a single Document Conversions Load Balancer Service enabled.
Document Conversions Launcher Service 
This service schedules and initiates the document conversions on a server.
Multiple launchers can exist in the same farm.
Windows SharePoint Services Incoming E-Mail
This service is responsible for receiving incoming emails and placing them in email enabled lists. 
This service can run on multiple servers
Windows SharePoint Services Outgoing E-Mail 
This is not technically a SharePoint service but refers to an SMTP server which SharePoint send outbound email to
Central Administration
This service enables the central administration interface that is required for farm-wide administration.
This service can only run on one server in the farm i,e. on any single Application server. 



How Solution (.wsp) is deployed to SharePoint farm?

  • WSP Solution can be deployed with PowerShell script using commands Add-SPSolution and Install-SPSolution.
  • Add-SPSolution will move your solution to SP Admin database.
  • Install-SPSolution will create a timer job on all WFE’s to push all files to 12/14/15 hive, DLL's to GAC, Web.Config changes etc. to the Front end servers where you have "SP Web Application" service running.
  • It doesn’t matter which server you are using to deploy your WSP with PowerShell. It can be Application server or WFE server.
  • The solution functionalities will be always executed on your front end server, your app server doesn’t need the WSP artifacts.



Monday 11 May 2015

The "TransformFiles" task was not given a value for the required parameter "IsDebugging"

Good Morning Friends! :)

Hope you all must be doing good!

I am going to write today about one issue which sometimes occur when you try to upgrade your SharePoint Project from Visual Studio 2010 to Visual Studio 2013.

It can also occur in any new SharePoint Project in Visual Studio 2013 directly if you try to add "PostBuildEventDependsOn" property in .csproj/.vbproj file(from notepad) to generate the .wsp at the time of building the project.

Exception you get is:
The "TransformFiles" task was not given a value for the required parameter "IsDebugging"


When you add the same properties to .csproj/.vbproj file (from notepad) in Visual Studio 2010 SharePoint project then it works well and creates the .wsp correctly there. Notice the "\v10.0\" in the project path for VS 2010.

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\SharePointTools\Microsoft.VisualStudio.SharePoint.targets" />
  <PropertyGroup>      
                 <PostBuildEventDependsOn>$(PostBuildEventDependsOn);CreatePackage</PostBuildEventDependsOn>
<PostBuildEvent>copy "$(TargetDir)$(TargetName).wsp" "$(SolutionDir)DeploymentFiles\$(TargetName).wsp"</PostBuildEvent>

  </PropertyGroup>



But when you try to use the same settings in Visual Studio 2013 project then it doesn't work and throws the excpetion The "TransformFiles" task was not given a value for the required parameter "IsDebugging".

Notice the "\v12.0\" in the project path for VS 2013.

  <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v12.0\SharePointTools\Microsoft.VisualStudio.SharePoint.targets" />
  <PropertyGroup>    <PostBuildEventDependsOn>$(PostBuildEventDependsOn);CreatePackage</PostBuildEventDependsOn>
<PostBuildEvent>copy "$(TargetDir)$(TargetName).wsp" "$(SolutionDir)DeploymentFiles\$(TargetName).wsp"</PostBuildEvent>
  </PropertyGroup>


Exception says that property "IsDebugging" which is a required property is not provided with any value.

After carefully examining the "Microsoft.VisualStudio.SharePoint.targets" file, it was observed that this property "IsDebugging" is being used inside "TransformFiles" element.

After googling a lot for this exception, haven't found any resolution.

While troubleshooting, I just provided value for "IsDebugging" like below and Voila! It worked! There was no more exception after building the solution and .wsp was generated perfectly.

  <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v12.0\SharePointTools\Microsoft.VisualStudio.SharePoint.targets" />
  <PropertyGroup>
<IsDebugging>False</IsDebugging>    <PostBuildEventDependsOn>$(PostBuildEventDependsOn);CreatePackage</PostBuildEventDependsOn>
<PostBuildEvent>copy "$(TargetDir)$(TargetName).wsp" "$(SolutionDir)DeploymentFiles\$(TargetName).wsp"</PostBuildEvent>
  </PropertyGroup>

Please note one important thing here, I had to use PostBuildEvent command to copy .wsp to some another location. When I wasnot using this command, .wsp file was not getting build at bin\release folder.

Hope it will help someone out there to save his/her day.

Happy Learning! :)

Tuesday 28 April 2015

BreadCrumb shows old path after moving sharepoint 2010 site to different location

Good Afternoon Friends!

Hope you all are doing good! :)


We moved one of the subsite recently to the upper level from "Site Settings >> Site content and structure". It successfully moved to the upper level in hierarchy. No problem. A piece of cake.

But when we checked the moved site from top level navigation, we observed that Breadcrumb was showing still the old path. Breadcrumb was the custom control but it was using nothing more than a SiteMap control and a SiteMapProvider "CurrentNavSiteMapProviderNoEncode".

With this issue, there was one more lined up. Current Site Navigation control (SharePointWebControls:AspMenu with PublishingNavigation:PortalSiteMapDataSource) on the page (having SiteMapProvider as "CurrentNavSiteMapProvider") was showing subsites based on previous parent site reference.

The issue seemed because of the SharePoint Object Cache which was not refreshed. SiteMapProviders are cached in the SharePoint object cache. One way to refresh the cache was to reset the app pool for that web application in IIS. But since this was the Production and a working day and not a showstopper issue, we didn't want to put Customer into trouble.

We checked the Current Navigation and Global Navigation items from "Site Settings >> Navigation" and surprisingly those items were shown correctly there. After observing those navigation items, we just clicked on the "Ok" button(without doing any changes) and then checked the breadcrumb and Site navigation controls again on the site's main page.

And we saw that both Issues were FIXED automatically :)

How this happened?

Well, this could be because by just clicking the "Ok" button in Navigation settings might have refreshed the SharePoint Object Cache completely (which caches "SiteMapProviders")

And hence the old cached references got refreshed for Site Map Providers and it showed new values correctly in Breadcrumb and Site Navigation control.

There is one good article from Paul to how to refresh object caches and breadcrumbs when any site is moved to some different location in SharePoint.

Hope it will help somebody out there.

Happy Learning! :)






Wednesday 22 April 2015

How list Versioning Settings values are stored in Content Databases? - Sharepoint 2010

Good Morning Friends!

Hope you all are doing good! :)

Recently in our Project, during deployment, we came across few problems. Customer wanted to get rid off approval process for image and document libraries for publishing sites but they wanted to exclude "workspaces" sites. By workspaces sites means all sites which were coming under paths like "/sites/", "/projects/" & "/workspaces/".

So we prepared a powershell script for updating all those libraries inside publishing sites. But there was one glitch in the script, script only excluded publishing sites under "/workspaces/" path and applied settings on publishing sites under "/sites/" and "/projects/" paths whereas we wanted to exclude all 3 workspaces paths. And to add to this problem, we didn't even had previous versioning settings logged to any file during script execution.

Now Customer wanted to have those old versioning settings back in place for "/sites/" and "/projects/" workspaces sites.

To compare the old versioning settings with new settings, we were thinking of couple of options.

One option was to compare old versioning settings from Old content database backup with Current content DB. But this was not very straight forward as there can be several content databases and it became very tedious job to find in which database the particular site and its lists belongs.

After finding out in which Content DB's the site and lists belongs, We would now need to fire a sql query to find out what is the value for different versioning settings from Content DB table.

But Where exactly values of different list Versioning settings are stored in Content Database?

and How its stored?

Versioning Settings values are stored in AllLists table in "tp_flags" column. List flags is an 8-byte unsigned integer bit mask that provides metadata about the list, which can have one or more flags set. List Flags identify an implementation-specific capability.

You can execute following SQL query specific to Content Database (where your list belongs) to identify whether moderation is enabled for the list or not. If the value returned by sql query is Zero then moderation is not enabled, and if other than Zero then moderation is enabled.

Select cast(tp_flags as bigint) & 0x0000000000000400 from allLists  --(where tp_WebID='< >' & tp_title = '< >')

0x0000000000000400
This list has moderation enabled, requiring an approval process when content is created or modified.

Similarly you can fetch values for different versioning settings like whether the versioning is enabled for list, whether minor version is enabled,  whether force checkout is enabled and so on.

There is list of all such List flags in this MS blog https://msdn.microsoft.com/en-us/library/hh646650(v=office.12).aspx

By comparing these db table flag values from Old and Current Content Databases, you will be able to compare values for different Versioning Settings.

In our case we were not having access to SQL database backups so we were not able to compare values from Content DB's.

Instead we moved to Second option by Restoring whole Sharepoint Farm backup on Test Enviornment and then Compared list versioning settings values from Powershell script.

Hope it will help somebody out there!

Happy Learning! :)






"Show more results" link doesnt show up in core results webpart - Sharepoint 2010

Good Afternoon Friends!

Hope you all are doing good! :)

Today we will talk little about Search Core result web part's property "Show more results" link.

In Core Results web part, you might have noticed that even though you have checked box "Show More Results Link", you are not able to see the "View more results >>" link on the screen even if the results are more than number mentioned in "ResultsPerPage" property.



After spending some time investigating with this issue and googling, I found that there is one more web part property which needs to be updated. Without this, View More link will not be visible.

 The property name is "MoreLinkUrl". But this property is not visible from UI.

So how to update this property?

Edit the Page and in edit mode, export the Core results web part. Open the exported web part in notepad. You will find "MoreLinkUrl" property like below.


Edit the property to add the link of newly created page in Pages library. This new page "MoreResults.aspx" will host a Core results web part of the same configuration and will show ALL results as per the search scope.


After editing the .webpart file, upload it to the Web parts gallery. And add that web part to the main page.

You will now see the "View More >>" link on the main page and it will have redirection link as "MoreResults.aspx".


Happy Learning! :)





Using multiple Core results webpart on single page - Sharepoint 2010

Good Afternoon Friends!

Hope you all are doing good :)

Today we are going to discuss briefly about one situation where we might be required to use Multiple Core Results web part on a Page.

Consider for example 3 web parts on a single page are configured to use separate search scopes and is expected to show different results as per those search scopes. But you notice that after applying all the correct configurations to the webparts, still webparts (which are above in order)  are showing the results of the webpart which is the bottom most.

You go back and check all the search scopes again and again in webparts, but still no luck. I too encountered this situation and was not getting the answer for it.

What exactly is going wrong here?

While doing some googling, Finally I found the reason for it. Its because of the Core Results Webpart property "Cross-Web Part Query ID". Its the culprit.



I checked the property for all 3 web parts and it was showing as "Query 2" for all. When I changed this property for other 2 web parts (i,e. 2nd web part = Query 3 & 3rd web part = Query 4)  Voila!, It started showing results correctly as per the respective search scopes.

In reality, Cross-Web Part Query ID property connects web parts that displays the same query Id.

If we want to keep the same Cross-Web Part Query ID for all the web parts then only the first Web Part can be edited to change this property. All of the other Search Core Result Web Parts that share the same ID are affected by the change.

Remember we only have following 4 values present in this property,
Query 2
Query 3
Query 4
Query 5

This means, you can use maximum 4 core results webparts on a single page (if all of them are using different search scopes).

Some details are available in this MS blog Change how search results appear in the Search Core Results Web Part (Search Server 2010)


Happy Learning! :)











Wednesday 1 April 2015

Migration of Site Collections


Good Morning Friends! :)

Today, I am going to discuss about couple of Migration Strategies that can be used to migrate whole site collections from one web application to another and on the same SharePoint version. We tried these strategies on SharePoint 2010 and I think It can very well be used on SharePoint 2013 as well.

Typical scenario for migration of site collections can arise when Customer wants to move some of their site collections from Intranet to Extranet. 


First strategy is using Backup & Restore approach:

You can automate migration by executing all below steps from one single powershell(.ps1) file.


Step 1) To avoid any updates and loss of data during migration on the site collection to be migrated, first set the site collection as Read-Only using command Set-SPSite (for e.g. on Intranet application)

Step 2) Start backing up the site collection using Backup-SPSite command. It can take some time and please make sure you have sufficient space on the physical disk.

Step 3) After backup is succeeded, Start Restoring the site collection on another web application using command Restore-SPSite (for e.g. on Extranet)

Step 4) Remove read-only status of site collection from Extranet application using Set-SPSite command

Step 5) Delete the site collection from Intranet using  Remove-SPSite command

This strategy is useful when you are not allowed to access SQL Server and want to keep the backup of migrated site collection on your physical drive. 

But this has few drawbacks like you will need lots of empty space on the physical drive and second it takes lot of time to do backup and restore. So if you are OK with these issues then you can go ahead with this strategy.


Second strategy is using Content DB and Move Site collections:

You can automate migration by executing all below steps from one single powershell (.ps1) file.

Step 1) Create new content DB to Intranet application using New-SPContentDatabase command

Step 2) Use Move-SPSite command to move site collection to this new content DB. Repeat this step for all site collections.

Step 3) Detach this new content DB from Intranet web application using command Dismount-SPContentDatabase

Step 4) Attach the content DB to Extranet web application using Mount-SPContentDatabase 


It will require that you have an access to SQL server for performing operations on DB.

This strategy has an advantage that it doesn't require any space on actual physical disk and is very much faster as compared to the first approach. It may require only 3 mins to move site collections of sizes 50-100 GB. Whereas with approach 1 you may require 30-45 mins to restore sites back.


You can decide on any strategy from above based on the situation. 

Following are the scripts made available for both strategies.



Script for First Strategy (Backup and Restore):

Script requires SitesToMigrate.xml as an input file.

File 1) SitesToMigrate.xml

<?xml version="1.0"?>
-<Root><SiteCollection Url="http://test/sites/testsite1" ManagedPath="sites" Name="testsite1"/><SiteCollection Url="http://test/workspaces/testsite2" ManagedPath="workspaces" Name="testsite2"/></Root>


File 2) MigrateSites.ps1

<#
.SYNOPSIS
This script performs following steps to migrate workspace site collection from Intranet to Extranet web application.

1. Read sites to migrate from "SitesToMigrate.xml" and for each site perform following steps
2. Set site collection to read-only mode
3. Get a backup of the site collection from Intranet
4. Restore the site collection to extranet web application
5. Set the site collection in extranet web application to normal mode
6. Delete the original site collection from Intranet

.PARAMETER $ExtraNetWebApplicationURL
Extranet web application Url
#>

param
(
[parameter(Mandatory=$true)][string]$ExtraNetWebApplicationURL = $(throw '- Need parameter for Extranet web application Url')
)

$ErrorActionPreference = "Stop"

[xml]$sites = Get-Content SitesToMigrate.xml


$backupPath = ((Get-Item -Path ".\" -Verbose).FullName + "\Backup\") 
$logFile = ((Get-Item -Path ".\" -Verbose).FullName + "\Log.txt")
$xmlOutFile = ((Get-Item -Path ".\" -Verbose).FullName + "\xmlOutFile.xml")

$outLog = Get-Date;
out-file -encoding unicode -filepath $logFile -InputObject $outLog -Append -NoClobber

$outXML = "<Root>"
out-file -encoding unicode -filepath $xmlOutFile -InputObject $outXML -Append -NoClobber

$siteElements = ""

foreach($siteColl in $sites.Root.SiteCollection)
{
try
{
$siteElements = ("<SiteCollection Url='" + $ExtraNetWebApplicationURL + "/" + $siteColl.ManagedPath + "/" + $siteColl.Name + "'")
$siteElements = ($siteElements + " Name='" + $siteColl.Name + "'")
$siteElements = ($siteElements + " ManagedPath='" + $siteColl.ManagedPath + "'")

# 1. Set site collection to read-only mode with Set-SPSite
Set-SPSite -Identity $siteColl.Url -LockState "ReadOnly"

$siteElements = ($siteElements + " IsLocked='True' ")

# 2. Get a backup of the site collection with Backup-SPSite
Backup-SPSite $siteColl.Url -Path ($backupPath + $siteColl.ManagedPath + "_" + $siteColl.Name)

$siteElements = ($siteElements + " IsBackedUp='True' ")

# 3. Restore the site collection to extranet web application with Restore-SPSite
Restore-SPSite ($ExtraNetWebApplicationURL + "/" + $siteColl.ManagedPath + "/" + $siteColl.Name) -Path ($backupPath + $siteColl.ManagedPath + "_" + $siteColl.Name) -Confirm:$False

$siteElements = ($siteElements + " IsRestored='True' ")

# 4. Set the site collection in extranet web application to normal mode with Set-SPSite
Set-SPSite -Identity ($ExtraNetWebApplicationURL + "/" + $siteColl.ManagedPath + "/" + $siteColl.Name) -LockState "Unlock"

$siteElements = ($siteElements + " IsUnlocked='True' ")

# 5. Delete the original site collection with Remove-SPSite
Remove-SPSite -Identity $siteColl.Url -GradualDelete -Confirm:$False

$siteElements = ($siteElements + " IsRemoved='True' ")
$siteElements = ($siteElements + "></SiteCollection>")
}
catch
{
$siteElements = ($siteElements + "></SiteCollection>")

        # Log Exception
        $date = Get-Date;
        $outException = "Unhandled Exception," + $siteColl.Url + "," + $_.Exception.Message + "," + $_.Exception.ItemName + "," + $date
        out-file -encoding unicode -filepath $logFile -InputObject $outException -Append -NoClobber

$outException = "---------------------------------------------------------------------------------------------"
        out-file -encoding unicode -filepath $logFile -InputObject $outException -Append -NoClobber
}
out-file -encoding unicode -filepath $xmlOutFile -InputObject $siteElements -Append -NoClobber
}


$outLog = Get-Date;
out-file -encoding unicode -filepath $logFile -InputObject $outLog -Append -NoClobber
$outXML = "</Root>"
out-file -encoding unicode -filepath $xmlOutFile -InputObject $outXML -Append -NoClobber
#End



Script for Second Strategy (Content DB and Move Site):

Script requires SitesToMigrate.xml as an input file.

File 1) SitesToMigrate.xml

<?xml version="1.0"?>
-<Root><SiteCollection Url="http://test/sites/testsite1" ManagedPath="sites" Name="testsite1"/><SiteCollection Url="http://test/workspaces/testsite2" ManagedPath="workspaces" Name="testsite2"/></Root>


File 2) MigrateSitesWithMoveSite.ps1

<#
.SYNOPSIS
This script performs following steps to migrate workspace site collection from Intranet to Extranet web application.

1. Create new content DB to Intranet web application server
2. Read sites to migrate from "SitesToMigrate.xml"
a. Use Move-SPSite to move each site collection to this new content DB
3. Detach this new content DB from Intranet web application
4. Attach the content DB to extranet web application

.PARAMETER $IntraNetWebApplicationURL
Intranet web application Url

.PARAMETER $ExtraNetWebApplicationURL
Extranet web application Url

.PARAMETER $NewDBName
New DB Name

.PARAMETER $SQLDBServer
SQL DB Server Name
#>


param
(
[parameter(Mandatory=$true)][string]$IntraNetWebApplicationURL = $(throw '- Need parameter for Intranet web application Url'),
[parameter(Mandatory=$true)][string]$ExtraNetWebApplicationURL = $(throw '- Need parameter for Extranet web application Url'),
[parameter(Mandatory=$true)][string]$NewDBName = $(throw '- Need parameter for New DB Name'),
[parameter(Mandatory=$true)][string]$SQLDBServer = $(throw '- Need parameter for SQL DB Server Name')
)

$ErrorActionPreference = "Stop"

[xml]$sites = Get-Content SitesToMigrate.xml

$logFile = ((Get-Item -Path ".\" -Verbose).FullName + "\Log.txt")
$xmlOutFile = ((Get-Item -Path ".\" -Verbose).FullName + "\xmlOutFile.xml")


$outLog = Get-Date;
out-file -encoding unicode -filepath $logFile -InputObject $outLog -Append -NoClobber

$outXML = "<Root>"
out-file -encoding unicode -filepath $xmlOutFile -InputObject $outXML -Append -NoClobber

$siteElements = ""
$dbElements = ""

try
{
#Create new content DB to Intranet web application server
New-SPContentDatabase $NewDBName -DatabaseServer $SQLDBServer -WebApplication $IntraNetWebApplicationURL -Confirm:$False

$dbElements = "<NewContentDBCreatedInIntra>True</NewContentDBCreatedInIntra>"
out-file -encoding unicode -filepath $xmlOutFile -InputObject $dbElements -Append -NoClobber

foreach($siteColl in $sites.Root.SiteCollection)
{

try
{
$siteElements = ("<SiteCollection Url='" + $ExtraNetWebApplicationURL + "/" + $siteColl.ManagedPath + "/" + $siteColl.Name + "'")
$siteElements = ($siteElements + " Name='" + $siteColl.Name + "'")
$siteElements = ($siteElements + " ManagedPath='" + $siteColl.ManagedPath + "'")

# should we lock site collection before moving? I think yes, as if someone changes anything in existing site before unmounting content db then?


# Use Move-SPSite to move site collection to this new content DB
Move-SPSite $siteColl.Url -DestinationDatabase $NewDBName -Confirm:$False

$siteElements = ($siteElements + " IsMoved='True' ")
$siteElements = ($siteElements + "></SiteCollection>")
}
catch
{
$siteElements = ($siteElements + "></SiteCollection>")

        # Log Exception
        $date = Get-Date;
        $outException = "Unhandled Exception," + $siteColl.Url + "," + $_.Exception.Message + "," + $_.Exception.ItemName + "," + $date
        out-file -encoding unicode -filepath $logFile -InputObject $outException -Append -NoClobber

$outException = "---------------------------------------------------------------------------------------------"
        out-file -encoding unicode -filepath $logFile -InputObject $outException -Append -NoClobber
}


out-file -encoding unicode -filepath $xmlOutFile -InputObject $siteElements -Append -NoClobber
}

# Detach this new content DB from Intrasite
Dismount-SPContentDatabase $NewDBName -Confirm:$False

$dbElements = "<NewContentDBDismountedFromIntra>True</NewContentDBDismountedFromIntra>"
out-file -encoding unicode -filepath $xmlOutFile -InputObject $dbElements -Append -NoClobber


# Attach the content DB to extranet web application
Mount-SPContentDatabase $NewDBName -DatabaseServer $SQLDBServer -WebApplication $ExtraNetWebApplicationURL -Confirm:$False

$dbElements = "<NewContentDBMountedOnExtranet>True</NewContentDBMountedOnExtranet>"
out-file -encoding unicode -filepath $xmlOutFile -InputObject $dbElements -Append -NoClobber

}
catch
{
        # Log Exception
        $date = Get-Date;
        $outException = "Unhandled Exception,," + $_.Exception.Message + "," + $_.Exception.ItemName + "," + $date
        out-file -encoding unicode -filepath $logFile -InputObject $outException -Append -NoClobber

$outException = "---------------------------------------------------------------------------------------------"
        out-file -encoding unicode -filepath $logFile -InputObject $outException -Append -NoClobber
}

$outLog = Get-Date;
out-file -encoding unicode -filepath $logFile -InputObject $outLog -Append -NoClobber

$outXML = "</Root>"
out-file -encoding unicode -filepath $xmlOutFile -InputObject $outXML -Append -NoClobber
#End


Happy Learning! :)


Monday 9 March 2015

Site Title Casing Issue (Sharepoint 2010)

Good Morning Friends! :)

How are you all? It's been a long time I haven't written a post.

Now starting again to write on some interesting topics. Hope you will like it :)



In our Customer's Intranet site, we have a local news webpart on front page. Its a custom control which reads the site news based on hardcoded "LocalNews" keyword(which is a Site Title) and show news pages from that site in the webpart.

One of the Customer's office location was facing a problem that they couldn't see Local news on the front page.

Problem was custom webpart was not able to find the local news site as the site's title was in lowercase "localnews" whereas in webpart there was a check for "LocalNews" i,e. title case.

Solution was quite simple just to rename the Site title to "LocalNews" instead of "localnews".

When we updated the Site Title from "Site Settings - Look and Feel" section, it was still showing the old value i,e. "localnews" and was not taking the value as "LocalNews"

We googled a lot to find out the reason for this but couldn't find anything useful.

After some time, while troublshooting, we tried updating the value of site title to some other name such as "LN". It was now taking the site title as "LN" and hence then again we changed the title to "LocalNews". Now the site title was correctly showing as "LocalNews" and not "localnews".

By this change, our front page local news webpart started to show news correctly in webpart :)

This indicates that site title must be different when we try to change its casing.

This was very small yet interesting workaround for resolving the issue.

Hope it will help to save time for some of you.

Happy Learning! :)