Feeds:
Posts
Comments

Archive for the ‘PowerShell’ Category

UPDATED: Find the new Youtube Link below!

Dear all,

episode 4 of SP5 is ready! This time it is dealing with the topic of moving site collections from one content database to another. Click below to watch the video (UPDATED):

Remark: If you want to create a new site collection using a specific content database, you need to use PowerShell, specifically the New-SPSite cmdlet:

New-SPSite –ContentDatabase <DBName>

This cannot be done from within Central Administration.

The involved cmdlets are:

Get-SPSite (lists site collections)
Get-SPContentDatabase (list content databases)
Move-SPSite (list content databases)
New-SPSite (create new site collection, specify content DB)

Important: After moving a site collection from one content DB to another, an iisreset is required. Be aware that this will cause a service disruption for some time (depending on your server’s configuration). Be sure to execute this only if you are fully aware that this will cause all websites to be inaccessible for some time.

Disclaimer: All tutorials are provided as is. You are responsible for any changes undergoing your system that derive from following this tutorial. It is hence recommended to consult your administrators and verify that the changes cannot harm your IT environment in any way.

Stay tuned till the next time!

Martin

Read Full Post »

Dear all,

while you can plan and organize availability on farm level by configuring Network Load Balancing and also SQL Server database mirroring and failover clustering, you do also have the possibility to plan for high availability on service application level, especially for critical service applications like PerformancePoint. In order to perform this, you must have a failover database server along your normal SQL server.

 

Higher availability for PerformancePoint Services can be achieved by adding additional failover databases to the PerformancePoint Service Application.

 

Go to the Central Administration, choose the row of the PerformancePoint Services Application (don’t click the name, otherwise you’ll “Manage”), and select “Properties” from the ribbon. Just like in Fig. 1

 

image

Fig.1: Open the properties window for the PerformancePoint Service Application

 

Next, in the “Failover Database Server”, insert the name of your failover database server.

image

Fig. 2: Specify the database failover server

After you did this, click “OK” to confirm.

 

Before fully relying on this mechanism, it could make sense to do a test run to verify whether the failover is working at all.

 

Caution: Do not execute the following steps in a production environment, unless you know what you are doing. At all costs, before testing the settings, notify users, schedule downtimes and make sure to do this together with a SQL administrator. Before applying any changes in production, test them in a similar test environment. The following steps assume that you have a working failover cluster for SQL server. If you don’t, DO NOT PROCEED at this point. If you are having only a single instance of SQL server (tested or untested) or a failover cluster that has been untested or is known not to be working, DO NOT EXECUTE the following steps. Otherwise you might lose data and functionality of your SharePoint environment.

 

1. Open a PPS dashboard.

2. Then, shut the principal SQL server instance down (again: Caution! do not do this in a production environment or without experience. You might lose all or partial functionality of SharePoint temporarily). This is the machine that is running Configuration Manager.

3. The failover server should now take over all the workload of the principal server.

4. Refresh the dashboard. It should work fine.

5. Try to modify it to see whether also write operations work on the PPS failover database.

6. Make sure to start again the SQL Server instance and verify that everything is up and working again.

 

The PowerShell approach:

The same result can also be achieved using the following PowerShell cmdlet:

 

Set-SPPerformancePointServiceApplication –Identity <Identity> –DatabaseFailoverServer <Servername>

 

This is very straightforward and increases the availabilty of your PerformancePoint Services.

Upshot: If you have a running SQL Server failover cluster, with little effort you can achieve high availability also for you Business Intelligence data. Not bad, is it?

 

Stay tuned, and till next time!

Martin (still in Calabria)

Read Full Post »

Dear all,

the same way that you can Toggle the Developer Dashboard using STSADM.exe, you can also toggle it using PowerShell. It is slightly more complicated, but works just as fine and it’s also faster than the STSADM command. Let’s have a look:

$service = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$ddSettings =$service.DeveloperDashboardSettings
$ddSettings.DisplayLevel = [Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel]::OnDemand
$ddSettings.Update()

What it does, is retrieving the content web service, then retrieve the service’s dashboard developer settings and setting their display visibility level. It can be set to either of these:

[Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel]::On
[Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel]::Off
[Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel]::OnDemand

If you execute script, do it line by line or store them as a scripted .ps1 file before. There will be no success messages, but if you don’t get an error or warning from the PowerShell

Make sure you run these in a SharePoint Management Shell that you started with “Run as administrator”. Otherwise it will not work. Also, using the SharePoint Management Shell saves you from needing to add the SharePoint library using the Add-PSSnapin cmdlet. If  you should decide to open just a “normal” PowerShell command interface, make sure to execute the following:

Add-PSSnapin Microsoft.SharePoint.Powershell

Then run the above mentioned script, it should work fine. Please make sure to test any scripts before running them in a production environment. As usual, I cannot take responsability for any damage caused by scripts on this page. They are provided as-is. Adaptations could be necessary to make it run successfully.

Best regards and stay tuned till the next time!

Martin (currently enjoying the sun in Calabria!)

Read Full Post »

Dear all,

The developer dashboard is a very handy tool in Microsoft SharePoint Server 2010, when it comes to analyzing how your site is loading and finding potential bottlenecks. It displays information about databases, webservices, the current page itself and so on. You can see an example of the developer dashboard here. Once enabled, it can be found scrolling at the bottom of the page you want to analyze.

The Developer Dashboard

There are three states the developer dashboard can be in:

  • On: Displayed
  • Off: Not displayed
  • On Demand: Can be toggled by the user.

And you have three possibilities of turning it on or off:

  • STSADM.exe
  • PowerShell
  • SharePoint COM

In this post, we’ll just focus on the STSADM.exe method, since it is the fastest one. STSADM.exe is located in the HIVE folder of SharePoint 2010 (usually “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\”, and there in the “BIN” folder).

The STSADM.exe Method:

On:  stsadm -o setproperty -pn developer-dashboard -pv on

Off:  stsadm -o setproperty -pn developer-dashboard -pv off

On Demand:  stsadm -o setproperty -pn developer-dashboard -pv ondemand

Turning it on “On Demand” creates a new button in the menu, which is shown in the following picture:

On Demand Developer Dashboard Toggle Button

On Demand Developer Dashboard Toggle Button

That’s it! The command takes a few seconds to run and then quits with a “Operation successful” message.

Best regards and stay tuned till the next time,

Martin

Read Full Post »

Dear all,

 

Shallow Copy is one of the new features added by the SharePoint Server 2010 SP1. Citing Microsoft, it does the following:

 

Shallow copy is a migration technique in which structured site collection data is moved across content databases while the unstructured data remains untouched in its originally configured BLOB store.

 

Sounds good, doesn’t it? In other words: The effort to migrate RBS-enabled site collections is greatly reduced – because we don’t have to consider the moving of the BLOB content anymore. Good!

 

The shallow copy can be performed using the Move-SPSite cmdlet, by simply specifying the RbsProviderMapping parameter. Here is an example:

 

Move-SPSite -Identity <Url> -DestinationDatabase <DB> 
–RbsProviderMapping @{"sourceProvider1"="targetProvider1",
"sourceProvider2"="targetProvider2"}

 

As stated before, only the structured content database is copied, while the unstructured content, such as BLOB files lying on file systems, remains untouched. Only the ownership information for the BLOB content is copied to the destination database.

 

Stay tuned till the next time!

Best regards,

Martin

Read Full Post »

Older Posts »