A few Random development tricks - slighted trickery

CSS to block quicklaunch etc.


<style>
.ms-quicklaunch
{
display:none;
}
.ms-navframe
{
display: none;
}
.ms-globalTitleArea {
display: none;
}
</style> 

The following code is for a sharepoint redirect, just add it to a content editor web part

<meta http-equiv="refresh" content="10;url=http://MYSERVERNAME.com/Pages/default.aspx">

This code, below, taken from http://pathtosharepoint.com  will ADD the quicklaunch using a CEWP

<!-- Load and display Quick Launch - iframe version -->
<!-- Questions and comments: Christophe@PathToSharePoint.com -->
<!-- Paste the URL of the source page below: -->

< iframe id="SourcePage" style="display:none;" src="http://[YourSite]/default.aspx" onload="DisplayQuickLaunch()"></iframe>
<script type="text/javascript">
function DisplayQuickLaunch()
{
var placeholder = document.getElementById("LeftNavigationAreaCell");
var quicklaunchmenu = null;
var SourcePage = document.getElementById("SourcePage");
try {
   if(SourcePage.contentDocument)
      // Firefox, Opera

      {quicklaunchmenu = SourcePage.contentDocument.getElementById("LeftNavigationAreaCell") ;}
   else if(SourcePage.contentWindow)
      // Internet Explorer
      {quicklaunchmenu = SourcePage.contentWindow.document.getElementById("LeftNavigationAreaCell") ;}
   else if(SourcePage.document)
      // Others?
      {quicklaunchmenu = SourcePage.document.getElementById("LeftNavigationAreaCell") ;}
}
catch(err) { alert ("Loading failed");}
var allDescendants = quicklaunchmenu.getElementsByTagName("*");
for (i=0;i<allDescendants.length;i++) {
allDescendants[i].removeAttribute("id");
allDescendants[i].removeAttribute("onclick");
allDescendants[i].removeAttribute("onfocus");
allDescendants[i].removeAttribute("onmouseover");
}
placeholder.innerHTML = quicklaunchmenu.innerHTML;
}
</script>

Migrating to Windows 2008 R2 from a 32-bit (x86) Server

Overview

Since Windows 2008 R2 only comes in a 64-bit flavor it is impossible to perform an in place upgrade on a Server running on x86 architecture for P2V or for whatever reason.  As such, a migration to a new 64Bit server is required.  These are the two possible options:

• Deploy a new machine and manually copy, recreate share permissions, Local users, groups etc.
• Use Windows Server Migration tools to copy and create local users and groups, copy data, copy share and folder permissions, etc.

This document covers the second bullet point.

Prepare the Target:

1. Deploy the target machine from an approved template.
2. After target is joined into the domain, install Windows Server Migration tools feature:
3. Open Server manager click on features, then click on add features
4. Scroll down and select the migration tools option, as shown:
5.  After selecting the Windows Server Migration tools, install it.
6. Open a command prompt and navigate to c:\Windows\System32\ServerMigrationTools
7. Share out a folder that the administrator account will be able to access across the network from the source machine, create this migration folder on the target server.  In other words, Just create a folder named migration, share it so that you’ll be able to access it from the source.
8. Create the migration package, go back to your command prompt and into the server migration tools directory under system32 and input the following command.  Note: the shared folder used in this example is named Migration and is on the C:\

SmigDeploy.exe /package /architecture X86 /os WS03 /path C:\Migration

(Image of actual command being run in a window on  a machine that has the path to the servermigrationtools folder defined in its environment variable)

Prepare the Source

1. Install powershell v 1.0 or higher on the source, go to this site http://support.microsoft.com/kb/968929 scroll towards the bottom and download and install the appropriate version of powershell for your servers architecture.  (WARNING: don’t install x64 architecture onto x86 machines or vice versa).  A restart is not needed to complete the install for version 2.0 powershell.
2. Make sure .Net Framework 2.0 or higher is installed, if it isn’t go here and download the appropriate installer for you architecture: http://www.microsoft.com/net/download , A restart will be needed to complete the install.
3. Navigate to the migration shared folder that you created on the target
4. Copy the entire folder from within the migration folder to the C:\ drive of the source machine.  If you created a package to migrate from a windows Server 2003 32 bit machine the folder you will be copying in this step is named SMT_WS03_X86.
5. Open a command prompt with admin priviledges (e.g. right click cmd.exe and choose run as administrator)
6. Navigate into the folder that you just copied in step 2, (e.g. cd c:\smt_ws03_x86)
7. Run the following command to register the tools in the 2003 machines registry

.\smigdeploy.exe

8. This will register the migration tools and open a powershell command window allowing you to proceed to the next section.

Migrate Local users and groups

Migrate the local users and groups prior to migrating files, folders, IIS webs, ntfs permissions, and share permissions. 

Firewall Pre-Requisites

To do this you’ll need to run the following commands on your windows 2008 R2 target and might have to run one command on the 32 bit machine:

2008 or 2008 R2

netsh advfirewall firewall add rule name=ServerMigration(TCP-In) dir=in program=%windir%\System32\WindowsPowerShell\v1.0\powershell.exe action=allow protocol=TCP localport=7000

 

netsh advfirewall firewall add rule name=ServerMigration(UDP-In) dir=in program=%windir%\System32\WindowsPowerShell\v1.0\powershell.exe action=allow protocol=UDP localport=7000

The 2003 machine will more than likely not have the firewall enabled and as a result will not need this command.

2003

 

netsh firewall add allowedprogram program=%windir%\System32\WindowsPowerShell\v1.0\powershell.exe name="ServerMigration" mode=ENABLE

 

1. In the powershell window that opened after you registered the migration package on the source computer enter the following command:

Export-SmigServerSetting -User All -Group -Path \\ServerName\Migration –Verbose

Notice: the –Path points to the server name and the migration share; so, if you shared your migration folder out as WindowsMigration, the path would be different.

2. Go to the target server, open a Windows PowerShell session with elevated user rights. To do this, click Start, click All Programs, click Accessories, open the Windows PowerShell folder, right-click Windows PowerShell, and then click Run as administrator.
3. Enter the following:

Add-PSSnapin Microsoft.Windows.ServerManager.Migration

(Note: this loads the server migration tools snap in into powershell)

Then enter,

Import-SmigServerSetting -User All -Group -Path c:\Migration –Verbose

Notice: the –Path points to C:\ drive and the migration folder since it is on this server

4. Wait for the task to complete and then verify local users and groups from the source to the target
5. Once you have verified that all users and groups were migrated, you’re ready to migrate files, folders, shares, etcetera

Migrate Files and folders

Source server – Step One

1. In the elevated powershell window enter the following:

Send-SmigServerData -ComputerName <DestinationServer> -SourcePath d:\users -DestinationPath d:\ users -Recurse -Include All -Force

Note: <DestinationServer> = the netname of your destination server and there is a space in between/ in front of -, but it is hard to see.

Hint: If you make the source path the same as the destination path, the migration will create the folder on the destination and copy all files into the destination folder while creating all permissions, share permissions, and webs.  We found that running the send-smigserverdata prior to the receive works better in SSANet.

If this fails, reverse steps one and two.

Target Server – Step Two

2. In an elaveted powershell window make sure you have the migration tools snap in loaded (see step 3 from the previous section).  Note: if you didn’t close the powershell window from the import you’re good to go.
3. Enter the following within 5 minutes of kicking off the send

Receive-SmigServerData

All progress will be shown on the source server, don’t restart the server or close the powershell windows on either source or target.

References:

http://technet.microsoft.com/en-us/library/dd379474(v=ws.10).aspx  - Contains detailed instructions, including what was described in this document.

Technet Video on Migration tools install into a 32 bit or 64 bit server. - http://technet.microsoft.com/en-us/windowsserver/ee914657.aspx

Good luck and Cheers, Stacy

Convert a classic based authentication SharePoint 2010 web application into a claims based web application that will use forms based authentication

This blog post attempts to bridge the gap between creating a claims based authentication web application versus converting a classic web application to claims, essentially step 1 of this blog: http://blogs.technet.com/b/mahesm/archive/2010/04/07/configure-forms-based-authentication-fba-with-sharepoint-2010.aspx


 New-SPAuthenticationProvider - http://technet.microsoft.com/en-us/library/ff607878.aspx

Here's how you create a new web application that uses claims based authentication, using powershell (step one of the first link in this blog).   Notice how $ap variable, below,  substantiates the new authentication provider and provides the membership provider and role provider names?

$ap = New-SPAuthenticationProvider -ASPNETMembershipProvider "membership" -ASPNETRoleProviderName "rolemanager"

Set-SPWebApplication -Name "Claims Windows Web App" -ApplicationPool "Claims App Pool" -ApplicationPoolAccount "redmond\appool" -Url http://<servername> -Port 80 -AuthenticationProvider $ap


Then notice how the set spweb application actually creates the new web app using that variable $ap

The user running these commands should be a member of the SharePoint_Shell_Access role on the config DB, and a member of the WSS_ADMIN_WPG local group on all front end servers.

Finally, When you provision\create a web application in SharePoint 2010 you get the option to enable Claims based authentication. However, after the provisioning there's no option in the GUI to turn it on if you wanted to switch from classic to claims.. PowerShell to the rescue once, again with the option to change from classic to claims based authentication using the lines below.

$App = get-spwebapplication “http://sp1:8000”
$app.useclaimsauthentication = “True”
$app.Update()

then set the membership and role providers

see this blog for the rest of the steps, and remember that this is a one way street and you cant go back to classic




http://blogs.technet.com/b/mahesm/archive/2010/04/07/configure-forms-based-authentication-fba-with-sharepoint-2010.aspx

 

An error has occurred after removal of an extended zone

Let's say you've applied the advice from unextending an extended zone and are now either getting a blank page after re-using the the vanity url or you're receiving a message that "Something has went wrong" or "An error has occurred". 

You ran Get-SPWebApplication http://sitename.com | Remove-SPWebApplication http://sitename.com -Zone "Intranet" and then the Intranet choice was available on the web application, the alternate access mapping for http://sitename.com was no longer associated with said web application and the world seemed right. 

It seemed right until that vanity url was re-extended the web application.  It was at this point that an error occurred.  Or if you re-extended the same vanity URL on a different web application you are now getting a blank page and no semblance of your SharePoint site.

Here's what to do:  Navigate to the physical storage for each site on each server that is a member of your web garden \ SharePoint Farm, barring the SQL boxes, and make sure that the site was removed from IIS. 

If you see the folder located there in the virtual directory, go back and first remove the site from IIS, as it is more than likely still there, then delete this folder.
 
In other words after unextending the site, navigate to inetpub\wwwroot\wss\virtualdirectories and make sure that the folder is gone, then look in IIS and make sure that the site is also not hanging around, if they are, delete them.  Repeat on each server that is a member of your farm (web garden) and then reset IIS on all servers in the farm.

Sorry about not including that in the original post, good luck and cheers!  Stacy