Home > Blogs
Recently, I have been getting a lot of questions about what are the things we should consider before upgrading to SharePoint 2010. Here is my list:
- Ensure your environment is fully functioning before you perform an upgrade. No need to carry over any old issues into your new SharePoint 2010 environment
- Make sure you meet hardware requirements: 64-bit hardware, 4 cores CPU or better, 8Gb of RAM or better, enough disk storage, et cetera.
- Make sure you meet software requirements Windows Server 2008 SP2 or better, SQL Server 2005 SP3 or better, SharePoint prerequisites installed, member of Active Directory domain, and so on. Everything must be 64 bit.
- Plan browser support (IE6 is not supported) and Office client upgrade
- Get all your SharePoint servers to Service Pack 2 or later
- Run Pre-Upgrade check to identify potential issues that will prevent us from successfully upgrading to SharePoint 2010. Review the report. Fix the errors. Re-run pre-upgrade check utility. Repeat, if needed.
- Identify all customizations such as 3rd party webparts or look-n-feel changes. Make sure those will work properly in SharePoint 2010
- Backup all SharePoint databases. Seriously. Backup all SharePoint databases.
- Choose upgrade approach: in-place approach or database attach upgrade. Or hybrid approach.
- Test the upgrade process. Before you perform an upgrade in production environment, test the upgrade process and address any issues you found during testing
- UPGRADE all your SharePoint servers to SharePoint 2010 (finally)
- Evaluate the upgrade. Review logs, check update status troubleshoot issues and errors.
- Use Visual Upgrade to convert site collections to the SharePoint 2010 product look
- Completing the upgrade: configure service applications, update database permissions, configure authentication, validate the upgrade, etc.
- Enjoy the SharePoint 2010 awesomeness.
To learn more about how to build a sound SharePoint environment, check out our Upcoming Courses
If you get an error "An unhandled exception occurred in the Silverlight Application in SharePoint 2010" when you try to create a document library, list, site or anything in SharePoint 2010 (using new fancy Silverlight control), then it could be that security validation has been disabled Webpart Security Validation under Web Application General Settings in SharePoint Central Administration. Apparently, Silverlight application is unable to connect to the WCF endpoint configured by the product for enabling Client Object Model, if Security validation is set to Off. Enable it, and you should be fine…
If you get the following error "TF249063: The following Web service is not available: http://SERVER:17012/_vti_bin/TeamFoundationIntegrationService.asmx. This Web service is used for the Team Foundation Server Extensions for SharePoint Products. The underlying error is: The remote server returned an error: (404) Not Found. Verify that the following URL points to a valid SharePoint Web application and that the application is available: http:// SERVER:17012. If the URL is correct and the Web application is operating normally, verify that a firewall is not blocking access to the Web application.", when you try to create new projects in TFS 2010 or simply when you browse to SharePoint Extensions tab in TFS Administration Console, then most likely its caused by the fact that Team Foundation Server Extensions for SharePoint Products (aka TFS 2010 Solutions in SharePoint 2010 or 2007) were not installed properly. To resolve this issue you need to add those solutions manually to the solutions store and then deploy them:
- Open Command Prompt
- Change your directory to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\\bin\ (for SharePoint 2010) and C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\\bin\ (for SharePoint 2007)
- Add TFS 2010 solutions using stsadm.exe command as follows:
stsadm -o addsolution -filename "C:\Program Files\Microsoft Team Foundation Server 2010\Tools\Templates\Microsoft.TeamFoundation.SharePoint.wsp"
stsadm -o addsolution -filename "C:\Program Files\Microsoft Team Foundation Server 2010\Tools\Templates\ TswaWebPartCollection.wsp"
stsadm -o addsolution -filename "C:\Program Files\Microsoft Team Foundation Server 2010\Tools\Templates\Microsoft.TeamFoundation.SharePoint.Dashboards.wsp"
- Then deploy solutions using either SharePoint Central Administration site or stsadm.exe command as follows:
stsadm -o deploysolution -name Microsoft.TeamFoundation.SharePoint.wsp -local –force
stsadm -o deploysolution -name TswaWebPartCollection.wsp -local –force
stsadm -o deploysolution -name Microsoft.TeamFoundation.SharePoint.Dashboards.wsp –url "YOUR WEB APP URL" –force
- Go back to TFS Administration Console and Grant Access to your SharePoint farm
- Under SharePoint Web Applications tab, add SharePoint web application to be used for TFS-related SharePoint sites
- Under Team Project Collections, make sure that all your existing Project Collections are tied to your SharePoint instance.
That is all J
If you get "Load control template file /_controltemplates/TaxonomyPicker.ascx failed: Could not load type 'Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker' from assembly…" error in your event logs on SharePoint 2010 server, then it's most likely caused by "corrupted" code in TaxonomyPicker.ascx file. To fix the problem:
- Go to <drive>:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\CONTROLTEMPLATES
- Backup TaxonomyPicker.ascx before making any changes to it, then open TaxonomyPicker.ascx file to edit
- Find the following line: <%@ Control className="TaxonomyPickerControl" Language="C#" Inherits="Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker,Microsoft.SharePoint.Portal, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
- Replace ',' with ',', so the line looks like this
<%@ Control className="TaxonomyPickerControl" Language="C#" Inherits="Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker,Microsoft.SharePoint.Portal, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
instead of
<%@ Control className="TaxonomyPickerControl" Language="C#" Inherits="Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker,Microsoft.SharePoint.Portal,Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
When you upload a large file (over 50Mb usually) to SharePoint 2010, you might get an "Error 0x800700DF: The file size exceeds the limit allowed and cannot be saved" message. Obviously, the first thing you need to check is to ask your SharePoint administrator what is your current file size upload quota. If the quota is not a problem, then the error is most likely caused by a local restriction set on Web Client service. By default, Web Client file size limit is set to 47Mb or so. To increase this limit:
- Open Windows Registry using regedit command
- Browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
- Right click on the FileSizeLimitInBytes and click Modify
- Click on Decimal, and type 4294967295 and click OK
- Restart Web Client service using Services snapin.
This will increase the Web Client file size limit to 4Gb, which is a maximum file size you can upload using WebDAV. Please note, that this will only address Web Client service restrictions, and will not increase your SharePoint quota. Only your SharePoint Administrators can do that, so be nice to them J
If you need to run load tests (or any other tests) against your web application, the most efficient way to do it is to use "the cloud": Amazon Elastic Cloud or Windows Azure servers. Why? Two simple reasons:
- It's easy spin up as many servers as you need, which make it easier to scale up or down your test rig environment
- It's external to your environment, which is necessary to make your tests closer to a real life scenario
I won't bore you with details on how to set up your TFS environment and all. We're all adults; we know how to read install guides. I will only cover the things are not in any of those guides.
Server instance setup in Amazon EC2 (applicable to Windows Azure as well):
- Pick large instance type or better. Small instance just is not powerful enough.
- Use Windows Server 2008 operating system as host. Amazon EC2 does not support Windows Server 2008 R2 yet, and there is no good reason to still use Windows Server 2003 operating system.
- Use an instance with SQL Server 2008 Express pre-installed to save time, unless you think your databases will be larger than 4Gb (very unlikely scenario in this cases)
- When going through "Launch an instance" wizard, at the Security Groups screen, pick Default group and create new security group (you don't have to configure new security group now, this can be done later). Make sure both of those groups were selected as this will save you a lot of headache later.
- Assign public IPs to your "cloud" servers and make sure that ISP that hosts your web application does not block or quarantine those IPs.
Host OS setup:
- Disable Simple File Sharing. I am not sure why this feature is enabled on the servers.
- Add your service account(s). To keep these notes simple, we will stick with one service account: tfsservice. Make sure all of your server instances have the same user accounts added (with the same passwords, of course)
- If you're feeling lazy, grant your service account a local administrator's permissions
- Make sure all of your "cloud" servers can see one another. If not, tweak your security groups in AWS Management Console.
TFS 2010 server tweaks:
- Make sure that the user account with the same name and password as the service account on the cloud servers exists in the environment that hosts TFS 2010. Could be a local account on the TFS server or domain account.
- Make sure that this service account is a member of Project Collection Administrators group, Project Collection Service Accounts group, and Project Collection Test Service Accounts group. Use tfssecurity.exe to add your user to those groups, if GUI does not let you.
- In some cases, using SSL when connect to your TFS server does not work, so configure your TFS server to accept connections on HTTP port as well (for example, port 8080)
Test Controller configuration:
- Make sure that the account you're using to run Test Controller service is a member of TeamTestAgentService local group
- Always use ".\" instead of a domain name or machine name when provide credentials. For example, ".\tfsservice", instead of "SERVERNAME\tfsservice"
- Do not register your test controller with any TFS project collection just yet
- Enter SQL Server instance that will be hosting your Load Test database
- Add virtual user licenses
Test Agent configuration:
- Always use ".\" instead of a domain name or machine name when provide credentials. For example, ".\tfsservice", instead of "SERVERNAME\tfsservice"
- Enter the machine name of your test controller. Use port default port 6901, unless you have configured your test controller to listen on a different port
I hope you found this info useful. If you have any questions or comments, shoot me an email at max [at] objectsharp [dot] com.
Just wanted to share this funny looking error I got on a SharePoint 2010 server recently: http://twitpic.com/3guyk8
I have no idea how or why this happened, but after I have refreshed the page it was gone and I never got it back. No errors were posted in the logs either J
Recently I have run into the situation where I was performing some maintenance work on SharePoint (backups, applying patches, you know – that kind of stuff), but the existing database connections to SharePoint were preventing me from doing my work. The way around this was to kill the remaining database connections, and here is how this can be done:
- Open SQL Management Studio
- Go to Management, and right click on Activity Monitor. Click on View Processes to get the list of all database connections
- Sort by a connection to a specific SharePoint database.
- Right click on a connection and click Kill Process.
- Do the same for all database connections to SharePoint, and you can carry on with your SharePoint maintenance tasks
Well, I was looking through SharePoint web.config file one time and asked myself how SharePoint knows where to find its contents. I know, it's a weird question to ask, but what can I say… I am that kind of person. Anyways, obviously looking through web.config did not yield any results, so I looked googled it. By the way, I do not know why, but I keep calling searching online as "googling" even though I switched to Bing a while ago. Old habits die hard, I guess, but I digress… After a little of research, I have found this blog post that has explained how SharePoint 2010 or 2007 finds its content. Basically, this is how it works:
- User types in the URL of the SharePoint website
- IIS gets a HTTP request, then handles it based on port number or a host header specified in the request
- Matching SharePoint website hands all requests to ASP.NET (thanks to wild card ISAPI mappings), which does all kinds of magic with the request
- Then, SPRequest HTTP module (defined in the web.config) gets into the play. SPRequest module does its magic too, and eventually request the location of the SharePoint configuration database from the registry. Connection string for the SharePoint configuration database is set using DSN key at HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Secure\ConfigDB (for SharePoint 2007) or HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0\Secure\ConfigDB (for SharePoint 2010). So, this is the registry value, you need to change, if you ever need to move configuration database.
- SharePoint configuration database knows where everything about the SharePoint farm, so it is (relatively speaking) "no brainer" from that point on… and the user sees an awesome SharePoint page on the screen.
It's that easy J
Recently, I have been installing and configuring a lot of TFS 2010 environments. Really, a lot of TFS 2010 (production, test, proof-of-concept) servers. Occasionally, I anger TFS "gods", so TFS installer throws an error and complain that certain TFS components does not have enough memory complete the install. It turns out that SharePoint component of TFS environment requires minimum of 1Gb of memory to operate. So does, TFS Build server… Otherwise, you'll end with this error in the installer log: " TF255157: The amount of RAM available on this computer is not sufficient to complete this process. You must have the following amount of RAM available: 1024 MB…"
Usually adding more memory to the servers hosting TFS components solves the problem, but if you can't wait to start playing with awesome TFS 2010, here is how you can override TFS 2010 installer behaviour:
- Create new environmental variable called TFS_IGNORE_VMEMORY and set its value to 1
- Restart your Team Foundation Configuration Wizard (not the entire server), and this time TFS "gods" will like you again.
Please note, just because you bypassed memory constraints preconfigured in TFS 2010 installer, it does not mean that you should not add more memory to your servers. Your TFS 2010 servers will work so much better, when its server meet (or exceed) the memory requirements…
Top ten facts about Chuck Norris and SharePoint 2010:
- Chuck Norris never starts an Approval workflow in SharePoint. Chuck doesn't need approval.
- Chuck Norris isn't afraid to customize, one look and SharePoint runs at peak performance
- Putting Chuck Norris in the SharePoint Visitors group is futile. Chuck always has Full Control.
- Chuck Norris doesn't have a SharePoint Disaster Recovery Plan. He doesn't recover data, only hostages.
- Chuck does not subscribe to Alerts. He knows what is happening before it happens.
- Chuck Norris IS the Governance Plan
- In SharePoint 2010, the Farm Administrators group is being renamed to 'Chuck's Group'.
- Chuck Norris never get's unexpected errors with SharePoint because he is always ready for everything.
- Chuck Norris doesn't prepare for SharePoint 2010. SharePoint 2010 prepares for him.
- SharePoint 2010 was a Chuck Norris idea.
Read more hilarious Chuck Norris & SharePoint 2010 facts at http://www.sharepointcomic.com/archive/2009/10/19/sharecomic-chuck-norris-and-sharepoint.aspx.
SharePoint 2010 allows administrators to pre-configure service accounts to be used when configuring SharePoint components. This way administrators don't have to remember or lookup usernames and passwords for service accounts every time they configure a new web application or SharePoint service. To configure managed service accounts in SharePoint 2010:
- Open SharePoint Central Administration
- Click on Application Management | Manage Web Applications
- Click on New button on the ribbon
- Fill in the text fields in IIS Website, Security Configuration, and Public URL sections, until you reach Application Pool section. This is where the fun begins...
- You can use one of already preconfigured managed accounts or create new one. To use an existing managed account simply pick one from the drop-down list. To create new managed account, click on Register New Managed Account
- Fill in the username and password fields (Note: for some reason there is no "confirm password" field, so make sure you type the password correctly the first time.) This screen also allows you to configure Automatic Password Change schedule. Pretty neat.
- Click OK to save newly configured managed account. Now you're back at Create New Web Application window, where you can see your managed account in the drop-down list.
- If administrators want to pre-configure managed accounts, they can do so in the SharePoint Central Administration. Click on Security | Configure managed accounts (under General Security section). Click on Register Managed Account to configure new managed account, or click on Edit to make changes to an existing managed account.
Just thought it was a good tip to share...
If you're getting "Access to the path 'C:\ProgramData\Microsoft\Team Foundation\Web Access\Cache' is denied" error when you try to access TFS 2010 Beta 2 via the Team Web Access, the problem most likely lies with missing NTFS permissions on the above-mentioned Cache folder. This problem often happens when you're running your TFS 2010 server on a domain controller, which is not ideal, but sometimes unavoidable, especially if you run all-in-one server setup.
There are two possible workarounds:
- First workaround is to assign Modify NTFS permissions on Cache folder on the TFS server to the service account used by SharePoint application pool in your TFS environment. Most likely, your SharePoint application pool (by default) runs under Network Service built-in account.
- Second workaround is changing SharePoint application pool to run under a domain account instead of Network Service account. I have read somewhere that this problem is caused by the fact that Network Service account cannot be added to a global group TFS_APPTIER_SERVICE_WPG, which is a domain group, not local to your TFS/DC server.
Note: If Cache folder does not exist, create one J
I recently came across draft guidelines from Microsoft that describe the requirements and considerations for planning to upgrade to SharePoint 2010. It's a one page document. It's easy to read to and to the point. I found it quite useful. Microsoft describes this document as:
"This model covers planning for an upgrade from Microsoft Office SharePoint Server 2007 or Windows SharePoint Services 3.0 to SharePoint 2010 Products.
It includes information about the following: Upgrade requirements: Hardware, operating system, and database
Upgrade process: specific steps to follow before, during, and after the upgrade"
You can download it from Microsoft Download Center: http://www.microsoft.com/downloads/details.aspx?FamilyID=eef6f604-9faa-4ea8-b000-569c656b7420&displaylang=en
If you need to run SharePoint 2010 on a domain controller, then you have to run the following PowerShell command on your SharePoint server to enable Sandboxed Solutions:
$acl = Get-Acl HKLM:\System\CurrentControlSet\Control\ComputerName
$person = [System.Security.Principal.NTAccount]"Users"
$access = [System.Security.AccessControl.RegistryRights]::FullControl
$inheritance = [System.Security.AccessControl.InheritanceFlags]"ContainerInherit, ObjectInherit"
$propagation = [System.Security.AccessControl.PropagationFlags]::None
$type = [System.Security.AccessControl.AccessControlType]::Allow
$rule = New-Object System.Security.AccessControl.RegistryAccessRule($person, $access, $inheritance, $propagation, $type)
$acl.AddAccessRule($rule)
Set-Acl HKLM:\System\CurrentControlSet\Control\ComputerName $acl
This PowerShell command will add an ACL access rule on your server, without which SPUCWorkerProcess.exe process won't start even though Microsoft SharePoint Foundation User Code Service will start.
P.S.: It's never a good idea to run any server applications (including SharePoint 2010) on your domain controllers, so please avoid it whenever possible.
If you're getting a blank page when you are trying to access SharePoint Central Administration site, then check your IIS settings. To be more specific, check the authentication settings for SharePoint Central Administration website in IIS. Make sure that you have Windows Authentication enabled and Anonymous Authentication disabled.
This must be the shortest blog post I have ever written. But taking into consideration that it was written on the first day of work after the holiday season, it's not so bad. Happy New Year everyone!!! J
It is definitely possible to use SharePoint 2010 beta 2 with TFS 2010 beta 2. You don't even need to do a lot of work to get them working together. A few things to consider:
- SharePoint 2010 beta 2 must be preinstalled (either on the same or separate machines) since TFS configuration wizard will not install SharePoint 2010 for you (only can only install WSS3)
- You need to manually enable TFS to log diagnostics information to SharePoint 2010 logs, because Microsoft changed the trace mechanism used in SharePoint 2010. To do that open SharePoint 2010 Management Console and type in
Set-SPDiagnosticConfig –AllowLegacyTraceProviders
- Since we are dealing with beta products, some things in the project dashboards might look a bit funny in IE8
- And last, but not least, if you decide to go with SharePoint 2010, do not forget to allocate a LOT of memory to SharePoint server (physical or virtual) because SharePoint will need it to function properly.
If you want to install and configure SharePoint 2010 in a standalone environment, but you do not want to use SQL Express and/or if you it to run in a workgroup environment, by default SharePoint 2010 configuration wizard will not allow you to do that. There is a way to get around this limitation though:
- Open SharePoint 2010 management shell, (you can find it at the same location as the SharePoint Central Administration link)
- Type in New-SPConfigurationDatabase to create new SharePoint configuration database manually
- Enter the name of the new SharePoint configuration database and hit Enter
- Enter the credentials that you want to use to create new SharePoint configuration database. Enter the password for those credentials when you get prompted to type in a passphrase and hit Enter. Your new SharePoint configuration database will now be created, just wait a few seconds/minutes.
- Run SharePoint configuration wizard, select Do not disconnect from this SharePoint farm option and continue with the configuration...
From what we've seen so far Windows 7 is already performing better than Vista, but if your PC seems sluggish then it's now much easier to uncover the bottleneck. Click Start, type RESMON and press Enter to launch the Resource Monitor. Click the CPU, Memory, Disk or Network tabs. Windows 7 will immediately show which processes are hogging the most system resources.
The CPU view is particularly useful, and provides something like a more powerful version of Task Manager. If a program has locked up, for example, then right-click its name in the list and select Analyze Process. Windows will then try to tell you why it's hanging - the program might be waiting for another process, perhaps - which could give you the information you need to fix the problem.
Yesterday I have witnessed a very weird behaviour of SharePoint navigation menu. Basically, SharePoint refused to save any changes (add/remove, hide, move, etc.) to SharePoint navigation menu. To make things even more confusing, it did not throw any errors or warnings in the event logs or SharePoint logs when this happened! In the process of troubleshooting this problem, we have systematically eliminated navigation provider(s), master pages, pages layouts, web.config(s), etc. as a potential source of this problem. We have checked everything and we're not able to come even close to finding a solution. Just before we started to plan on rebuilding the entire SharePoint environment to solve the problem, we have (almost accidently) found what was causing the problem. It turns out that what was causing this weird behaviour is that a default value of a single Boolean variable (_spSuppressFormOnSubmitWrapper) in INIT.JS file was changed from FALSE to TRUE. This almost makes sense, but... If you change the default behaviour of the submit button, shouldn't this change for effect the entire SharePoint environment, instead of singling only the navigation menu? Weird?! I am glad the problem was resolved though J
Change SharePoint Central Administration Account
- On servers running SharePoint Central Administration site run the following command:
stsadm -o updatefarmcredentials -userlogin DOMAIN\USERNAME -password PASSWORD
- On other servers not running SharePoint Central Administration site run the following command:
stsadm -o updatefarmcredentials -userlogin DOMAIN\USERNAME -password PASSWORD -local
- Run iisreset /noforce to restart IIS
- To make sure that this operation completed, open SharePoint Central Administration site >> Operations >> Timer job definitions and wait until Administration Application Pool Credential Deployment timer job disappears from the list.
Change Application Pool Accounts
There are two ways to change application pool accounts in SharePoint: first one using GUI, and the second using STSADM command. To change application pool accounts using GUI:
- Open SharePoint Central Administration site >> Operations >> Service Accounts (under Security Configuration section)
- Select Web Application Pool option and pick Web Service and Application Pool you would like to make changes to
- Enter username and password for application pool service account.
- You need to do this for each application pool account you would like to change on every SharePoint server in your farm
To change application pool account using STSADM command, run:
stsadm -o updateaccountpassword -userlogin DOMAIN\USERNAME -password PASSWORD –noadmin
Once again, you need to do this for each application pool account you would like to change on every SharePoint server in your farm.
There is also a third way to change application pool account – using LaPointe's custom STSADM command extensions: http://stsadm.blogspot.com/2008/10/changing-application-pool-identity-via.html
To change application pool account for SharePoint Central Administration web application run:
stsadm -o updatefarmcredentials -userlogin DOMAIN\USERNAME -password PASSWORD
Change Windows SharePoint Services Help Search account
To change Windows SharePoint Services Help Search account, run:
stsadm -o spsearch -farmserviceaccount DOMAIN\USERNAME -farmservicepassword PASSWORD
Change Default content access account (used by the Windows SharePoint Services Help Search service)
To change Default Content Access account, run:
stsadm -o spsearch -farmcontentaccessaccount DOMAIN\USERNAME -farmcontentaccesspassword PASSWORD
Change Office SharePoint Server Search service account
To change Office SharePoint Server Search account, run:
stsadm -o osearch -farmserviceaccount DOMAIN\USERNAME -farmservicepassword PASSWORD
Change Default content access account (used by the Shared Service Provider)
To change Default Content Access account, if the Infrastructure Update for Microsoft Office Servers is installed:
- Open SharePoint Central Administration site, click on your Shared Services Provider (in the Quick Launch, in the Shared Services Administration group)
- On the Shared Services Administration page, in the Search section, click Search Administration.
- On the Search Administration page, on the Quick Launch, in the Crawling section, click Default content access account
- On the Default Content Access Account page, in the Account box, type the domain and user name for the account (in the form DomainName\UserName)
- In the Password and Confirm Password boxes, type the password for the account.
- Click OK.
To change Default Content Access account, if the Infrastructure Update for Microsoft Office Servers is not installed:
- Open SharePoint Central Administration site, click on your Shared Services Provider (in the Quick Launch, in the Shared Services Administration group)
- On the Shared Services Administration page, in the Search section, click Search Settings.
- On the Configure Search Settings page, in the Crawl Settings section, click Default content access account
- On the Default Content Access Account page, in the Account box, type the domain and user name for the account (in the form DomainName\UserName)
- In the Password and Confirm Password boxes, type the password for the account.
- Click OK.
You can also use crawl rules to specify a different content access account or authentication method, read more at http://technet.microsoft.com/en-us/library/cc263052.aspx.
Change Shared Service Provider Service Accounts
To change Shared Service Provider Service Accounts, run:
stsadm -o editssp -title SHAREDSERVICESPROVIDERNAME -ssplogin DOMAIN\USERNAME -ssppassword PASSWORD
You need to run this command on every SharePoint server in your farm.
Change Excel Services Account
To change Excel Services Account:
- Open SharePoint Central Administration site, click on your Shared Services Provider
- Click edit Excel Services settings
- Enter username and password for the Excel Calculation Services account and then click the OK button.
Change Profile Access account
- Open SharePoint Central Administration site, click on your Shared Services Provider
- Click User profiles and properties
- Click Configure profile import
- Enter username and password and then click the OK button
One of the beautiful things about SharePoint is that you can schedule the time when you want your solution to be deployed or your page to be published. Recently, I have noticed that on one of our SharePoint farms, all deployment jobs were off by 3 hours. Naturally, I suspect that this problem must be caused by time zone misconfiguration. Obvious, right? What wasn't obvious is that to get this problem fixed you have to make sure that your time zone settings match in three separate places:
- Under local regional settings on your server (Do'h)
- Under Web Application General Settings (in SharePoint Central Administration >> Application Management). Ideally, all your web application will use the same time zone.
- Under Regional Settings in Site Settings for the specific site you're working with.
I realize that this is fairly small and easy to fix problem. But I just hate these annoying little problems that interrupt my afternoon nap... now back to sleep, I mean work J
This is a fourth and final post of the blog post series on building public-facing websites using SharePoint 2007. The first part was dedicated to the planning building public-facing websites using SharePoint 2007. The second part was dedicated to custom branding and development in SharePoint. The third blog post of the series was dedicated to search functionality in SharePoint. Let's start...
PAGE CONTENT
To me fresh and relevant content is the single most important aspect that defines your SEO rankings. You must strive to keep the content of your website fresh and read worthy. Take advantage SharePoint workflows and content expiration features to make it easier to generate new content. And, yes, having more text on the page is better than having more images.
Page Title is very important from SEO perspective. It absolutely must be descriptive and to the point. If you have to add your company name to the page title, add it to the end of the page title and separate it with double dashes "--" or something. Please try to avoid naming all pages in the site with the same page title.
Page Description must clearly summarize in one or two sentences what the page is about.
Even though keywords are not as important as they used to be (partially because keywords have been abused in the past.) So, it's up to if you want to use them or not. Personally, I don't.
PROPER HTML TAGGING
From my experience, the following HTML tags are important from SEO perspective:
- H1, H2, H3 ….
- Title
- Alt parameters for IMG
- META tags (maybe)
SEO-friendly URLs
Having SEO-friendly URLs is one of the easiest ways to get higher SEO rankings. As long as your page URL contains relevant keywords your page will have high(er) SEO ranking. It is amazing how something this simple can be so important. Use Imtech SharePoint SEO Slugs Feature to get Sharepoint build SEO friendly URL automatically when you create new page(s).
Sitemaps and robots.txt
Sitemap is a simple XML file describing the structure and the hierarchy of your website a search engine. It also provides the mechanism for letting search engines know when your pages have been added, removed or otherwise modified. You are supposed to use update your sitemap file every time you add a page, and ideally you should do that for every major search engine. To make things easier, use SharePoint SiteMap Generator.
As with any other public facing website, you should add robots.txt to your website to make sure that search engines do not crawl the sections of the site that you do not want them to. Here is an example of robots.txt file:
User-Agent: *
Disallow: /Search/
Disallow: /_layouts/
Dissalow: /ReusableContent/
Dissalow: /WorkflowTasks/
Dissalow: /SiteCollectionDocuments/
Dissalow: /SiteCollectionImages/
Dissalow: /Documents/Forms/
Dissalow: /Pages/Forms/
sitemap: http://www.SHAREPOINTSITE.com/sitemap.xml
Handling page redirects properly
It is very important to properly handle all your 404 errors. If you have any pages that have been moved or deleted, you must properly handle the HTTP request using URL rewriter and 301 permanent redirects. Here is a sample of the code from MSDN how to do that: http://msdn.microsoft.com/en-us/library/cc721591.aspx
To verify that your URLs return proper HTTP header, use URI Valet.
Handy SEO tools for SharePoint
- Imtech SharePoint SEO Slugs Feature: Imtech SharePoint SEO Slugs is a SharePoint Feature which hooks up to the Create Page Application Page provided with MOSS 2007. While creating a slug it not only separates all the different words with a hyphen (-) but also removes all the stop words as well!
- SharePoint SiteMap Generator: the process of keeping your site's sitemap.xml file current
- URI Valet: an online tool to check what HTTP header your URL returns.
As I have already mentioned in my previous blog post, ObjectSharp has been working with SharePoint technologies for years now: building public facing websites and intranet for clients, developing custom SharePoint web parts and features, designing custom templates, and so on... Oh yes, I forgot to mention hundreds of hours of SharePoint training (public and private) for developers and power users that we have taught to our clients. So, if you need any help customizing your SharePoint in any way, please email our Client Services Manager, Gisele Bourque, at gbourque@objectsharp.com, and/or if you need any training on SharePoint technologies email our Training Manager, Julie James, at jjames@objectsharp.com. Or visit our new and fancy SharePoint-based website at http://www.objectsharp.com.
Related resources:
On June 17, 2009, I will have my first talk at Toronto SharePoint User Group. The topic of the presentation is "Using SharePoint for Public Facing Websites". This presentation will cover (or attempt to cover) the best practices for building public facing websites using SharePoint, as well "gotchas" that I have came across working with SharePoint over the years. If interested, please come along…
Toronto SharePoint User Group usually meets 2 Bloor Street West, 12th Floor, Toronto (Bloor-Yonge subway station). Attendees tend to arrive at 6pm, grab a bite and socialize, meeting starts at 6:30 with Q&A, and the presentation starts by 7pm. The presentation wraps at about 8:20 or 8:30 and we end with prizes for the last 10pm. Some people get together for a beer after the meeting, but it's optional…
Please RSVP to Susie Ibbotson at sibbotson@nonlinear.ca if you're coming, in order to make sure that we order enough pizza J
This is a third post of the blog post series on building public-facing websites using SharePoint 2007. The first part was dedicated to the planning building public-facing websites using SharePoint 2007. The second part was dedicated to custom branding and development in SharePoint.
Plan SharePoint search: performance and sizing
Here is an excellent post on planning performance and sizing for SharePoint search: http://blogs.msdn.com/joelo/archive/2006/12/01/perf-and-sizing-data-from-msw-enterprise-search.aspx
Customize search box
To customize search box in SharePoint:
- Search for PlaceHolderSearchArea in the code
- Change Visible property of PlaceHolderSearchArea section to False: visible="false"
- Add Search Box web part
- To hide search scope drop down, add <DropDownModeEx xmlns="urn:schemas-microsoft-com:SearchBoxEx">HideScopeDD</DropDownModeEx> tag to the Search Box web part section of the code. More options for Search Scope Drop Down can be found at http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.portal.webcontrols.dropdownmodes.aspx
- To hide Advanced Search option, add <Property Name="ShowAdvancedSearch">false</Property> tag to the Search Box web part section of the code
- To change images for search buttons, modify GoImageUrl, GoImageUrlRTL, GoImageActiveUrl, GoImageActiveUrlRTL tags
- There are a lot more things you can customize in the Search Box, just read through the tags within PlaceHolderSearchArea section
There is also another way to customize search box by modifying SearchArea.xml under C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\OSearchEnhancedFeature. This is a much less elegant way, but it works.
Clean up your SharePoint search results.
To remove noisy search results that users do not want and/or do not have permissions to see:
Permissions issues with search
I have already blogged about some permissions issues with SharePoint search and anonymous users. Basically it has to do with the page layout inheriting certain classes that are not accessible to the anonymous users, but you can read the rest in my previous blog post: http://blogs.objectsharp.com/CS/blogs/max/archive/2008/02/20/sharepoint-search-and-anonymous-users.aspx
Block search engines from crawling non-public parts of the website
Activate ViewFormsPagesLockDown feature. This is a MOSS-only feature that disallows anonymous access to pages in the _layouts directory that inherit from LayoutsPageBase and disallows anonymous access any of the form or view pages (DispForm.aspx, AllItems.aspx). Otherwise, search engines will be able to view/crawl the parts of SharePoint you don't want them to see.
Best bets/Keyword feature
Use best bets feature in SharePoint search. Even though the interface is a bit awkward, I find this feature quite useful. Here are the instructions on how to manage best bets/keywords: http://office.microsoft.com/en-us/sharepointserver/HA011605771033.aspx
Performance optimization
Here are the best practices for search in SharePoint: http://technet.microsoft.com/en-us/library/cc850696.aspx.
The next topic of this blog post series will be dedicated to implementing or preserving SEO practices in SharePoint…
Related resources:
A tiny bug in Service Pack 2 of MOSS 2007 and WSS 3.0 has been discovered recently. Installing SP2 changes a product expiration date and sets your SharePoint install to 180-day trial. This expiration date bug should not affect the normal function of SharePoint, at least until the expiration date passes. After 180-day trial expires, customer's data, configuration or application code will still not be affected, but will render SharePoint inaccessible for end-users.
Microsoft promised a hotfix for this bug within the next 48 hours or so (KB971620). Meanwhile, you can easily fix this problem by re-entering your license key:
- Open SharePoint Central Administration
- Go to Operations
- Under Upgrade and Migration section, click on Convert license type
- Type in your license key and hit Enter
- That's it, problem solved.
Microsoft has just released Service Pack 2 for MOSS 2007 and WSS 3.0. It includes all the fixes prior to SP2, and also several enhancements
to improve server farm performance, availability and stability.
Here is the description of the for Service Pack 2 for WSS 3.0 and MOSS 2007.
To download the Service Pack 2 files:
Download Service Pack 2 for Windows SharePoint Services 3.0, x86 & x64
http://www.microsoft.com/downloads/details.aspx?FamilyId=79BADA82-C13F-44C1-BDC1-D0447337051B&displaylang=en
Service Pack 2 for Office SharePoint Server 2007, x86 & x64
http://www.microsoft.com/downloads/details.aspx?FamilyId=B7816D90-5FC6-4347-89B0-A80DEB27A082&displaylang=en
To update your WSS 3.0 server (needs to be run on every SharePoint server):
- Install Service Pack 2 for Windows SharePoint Services 3.0
- Install Service Pack 2 for Windows SharePoint Services 3.0 Language Pack (if applicable)
- Run the SharePoint Products and Technologies Configuration Wizard or "psconfig –cmd upgrade –inplace b2b -wait” in command line
To update your MOSS 2007 server (needs to be run on every SharePoint server):
- Install Service Pack 2 for Windows SharePoint Services 3.0
- Install Service Pack 2 for Windows SharePoint Services 3.0 Language Pack (if applicable)
- Install Service Pack 2 for Office SharePoint Server 2007
- Install Service Pack 2 for Office SharePoint Server 2007 Language Pack (if applicable)
- Run the SharePoint Products and Technologies Configuration Wizard or "psconfig –cmd upgrade –inplace b2b -wait” in command line
The version of content databases should be 12.0.0.6425 after successfully applying these updates.
To configure Active Directory Federation Services (ADFS) to work with SharePoint follow these instructions:
I have to say that it's awesome that we can configure SharePoint to use ADFS for user authentication as eases the burden on the SharePoint users because they don't have to remember another username and password. This is especially useful, if you're using SharePoint for public-facing website. I wish it was easier to configure though. Here are a few "gotchas" that I have encountered trying to get ADFS working with SharePoint:
- Extend your SharePoint web application to dedicate a separate section/URL for ADFS authentication
- The configuration guides are very exact, in the sense that everything must be done exactly as it says in the guide. If you do not follow the instructions to the point or if you miss a step or two, ADFS authentication won't work and it will be nearly impossible to figure out what you did wrong. More often than not, it will be a lot easier to uninstall/reinstall ADFS and try again
- Read your old notes on PKI and DNS, because configuring ADFS with SharePoint requires your PKI and DNS skills to be very sharp. Let's face it we tend to forget skills that we do not use on day to day basis
- Use ADFS Diagnostics Tool, it is a very useful tool
- Use ADFS Organizational Group Claims when assigning access permissions in SharePoint
- To assign permissions to a specific user (instead of the assigning permissions through ADFS Organizational Group Claims), user must log in to the SharePoint first.
Good luck!
This is a second part of the blog post on building public-facing websites using SharePoint 2007. The first part was dedicated to the planning building public-facing websites using SharePoint 2007.
Start with the minimal master page
Create a new blank master page using SharePoint Designer. I do not recommend basing your first custom master page on existing master pages templates, as those usually have a lot of SharePointy fluff that you do not necessarily want on your page. Start from scratch and only add the stuff you want/nee into your master page. Remember you can always come back to that master page and add more stuff in it later, if needed. Here is an excellent guide from Microsoft on how to how to create a minimal master page.
Building content types and page layouts
Building content types and page layouts is done in the following order:
When creating page layouts, try keeping the number of created page layouts to a minimum. Remember that page layouts are to be used only to define common "layouts" of your site, and you do not need a separate page layout for every single page on your site. Keeping the number of page layouts to a bare minimum will not only keep the size of your content database(s) to a minimum, but it will also you're your site a lot easier to manage.
Custom XSLT
A lot of the stuff in SharePoint is customized using XSLT files. For example, pretty much everything in Custom Query Web Part can be customized in XSLT file. There is also built in XSLT files that allows you to customize they some of the SharePoint content looks:
|
XSL Style Sheet |
Purpose |
Corresponding Web Part |
|
ContentQueryMain.xsl |
"Application" XSL style sheet |
Content Query |
|
Header.xsl |
Group headers for Content Query and Summary Links, title headers for Table of Contents |
Content Query, Summary Links, Table of Contents |
|
ItemStyle.xsl |
Content Query and Summary Link item styles |
Content Query, Summary Links |
|
LevelStyle.xsl |
Table of Contents level styles, which includes the site and its pages |
Table of Contents |
|
SummaryLinkMain.xsl |
"Application" XSL for Summary Links |
Summary Links |
|
TableOfContentsMain.xsl |
"Application" XSL for Table of Contents |
Table of Contents |
Here is a guide on how to create custom item styles in SharePoint: http://msdn.microsoft.com/en-us/library/ms551040.aspx.
Source Control might save your…
It's always (and I mean always) a good idea to store your custom code in the Source Control such as Microsoft Team Foundation Server 2008. I strongly recommend that you store in the source control all your custom branding items: master pages, page layouts, CSS files, javascripts, images, configuration files, etc… Utilizing source control will not only allow you to keep a better track of the changes to your code, but it will also make it easier to integrate your custom code into the rest of your SharePoint deployment solution.
Use features to deploy
Features in SharePoint could be used to optimize the process of deployment and re-deployment of SharePoint master pages and page layouts. Here is couple of guides on how you can deploy master pages and page layouts as a feature: http://sharepointmagazine.net/technical/development/deploying-the-master-page and http://www.sharepointnutsandbolts.com/2007/04/deploying-master-pages-and-page-layouts.html.
Also, you can use features to deploy reusable content, such as stylesheets, images, javascript files, configuration files, and, of course, the static pages that will always appear on the site (contact us, careers, etc.). This way moving that content between servers (between staging and production servers, for example), can be done using a simple mouse click (or two) instead of manually re-creating that content every step of the way.
Naturally, there is a lot more to SharePoint custom branding to development, but those are the items that I remember off the top of my head. I will update the blog post if I remember anything else.
Meanwhile, the next topic of this blog post series is everything about SharePoint search functionality on public facing websites.
Related resources:
ObjectSharp has been working with SharePoint technologies for years now: building public facing websites and intranet for the clients, developing custom SharePoint web parts and features, designing custom templates, and so on... Oh yes, I forgot to mention hundreds of hours of SharePoint training (public and private) for developers and power users that we have taught to our clients. But, despite this tremendous amount of SharePoint expertise ObjectSharp has built up internally, we never had time to move our own corporate website to Microsoft Office SharePoint Server 2007 platform. Long story short, finally, the vast benefits from moving to SharePoint platform outweighed the problems with dedicating our own internal resources to this project, and we have received a go ahead to proceed with the project. As a project manager for this SharePoint migration project, I would like to share with you the experience and the certain amount of wisdom we have gained from this project of moving our original "sophisticated and fancy-looking" website to the SharePoint-based web content management platform.
Goals
As in any other project, we have identified the goals that will determine if the projects have been successful or not:
- SharePoint-based website must look exactly (or as close as possible) as our original website
- SharePoint-based website must keep all existing functionality of the original website (public and administrative parts). All additional features for the new site will be added in the future website versions.
- SharePoint-based website must leverage existing SharePoint features and minimize the amount of custom code as much as possible
- The migration has to be transparent to our clients and the effect on our SEO ranking should be minimal
Planning infrastructure for SharePoint environment
To properly plan the infrastructure for SharePoint environment we need to know
- What are we going to use SharePoint for?
- What features of SharePoint will be utilized?
- How many visitors do we expect on the website? What's the expected server load?
- What will be the expected size of the website? How often will the website be updated?
- What are the performance requirements for the site?
- What are the availability requirements?
- What are our disaster recovery policy and standard maintenance schedules?
Here is an excellent link for estimating performance and capacity requirements for SharePoint servers: http://technet.microsoft.com/en-us/library/cc262405.aspx. Also if you require redundancy and availability in your SharePoint environment here are the guidelines from Microsoft for that: http://technet.microsoft.com/en-us/library/cc263044.aspx and http://technet.microsoft.com/en-us/library/cc748824.aspx.
Planning the development and production environments
It's always a good idea to separate development environment from the production environment. D'oh! Ideally, you will have separate SharePoint farm for developers, testers, content authors, and, of course, separate SharePoint farm for production.
For more information visit http://technet.microsoft.com/en-us/library/cc263209.aspx
Determine website structure and navigation
To comply with the project goals we needed to keep the existing site structure and navigation, so we have copied over the website structure to the new site. Luckily, SharePoint allows you to shape your site structure any way you want. We have created a single web application for our website, as it's more than sufficient. We have enabled anonymous access to the web application. We have also extended this web application to include support for SSL.
Now, we had to find the way to transfer our navigation menu to the new site. One of our consultants and Microsoft MVP, Justin Lee, had an answer for us: to use ASP.NET menu control with CssFriendly adapter. With a minimum of configuration tweaking and no custom code necessary we're able to get the menu transferred within an hour or so, but let's not jump ahead J
Determine authored elements: custom master pages, stylesheets, page layouts, content types, web parts, etc.
At this point, need to come up with a draft of what and how many master pages will we require, what kind of page layouts do we need, what stylesheets and javascripts will be included in master pages or page layouts, what content types and site columns we need to create, what web parts and/or features we need to develop, and so on and so forth. Basically, we need to try to determine the kind of content that will be added to our website, and the best way we can implement those authored elements.
Because master page will be loaded with every page, you need to make sure that your master page(s) contain only the minimal amount of content. In other words, only include primary stylesheet and javascript files to the master page to make sure that your pages load fast(er). Microsoft has an excellent guide on how to create minimal master page. Please note that minimizing the number of master pages will help to promote the consistency of styles and branding throughout your site (ideally, you would have only one master page).
When determining the page layouts and content types required for the website, you need to know what kind of content will be present on the page(s) and how it will be displayed to the public. I usually compile a list of different type of pages that the website will have, along with the list of entries that will be displayed on those pages. Having an original wireframe for the website will make this process so much easier.
Almost all content in our new SharePoint-based website will be in a form of a web part. Fortunately, SharePoint has a lot of built-in web parts that will be able to accommodate most of the content to be moved. Content Editor webpart, Content Query webpart, Image webpart are three web parts that you will probably use the most on your website. Naturally, sometimes your website will require functionality that SharePoint does not support out of the box, so Microsoft has provided the tools that will help you to develop all kinds of custom features. You need will to download Microsoft Office SharePoint Server 2007 SDK, SharePoint Extensions for Visual Studio 2008, and, of course, the copy of SharePoint DLLs from the SharePoint server! Please note, you can find a lot of information for SharePoint developers at http://www.microsoft.com/click/SharePointDeveloper/
Now it's time for a little bit of SharePoint branding and development….
Related resources:
There is a lot of conflicting information on the net whether it's possible to have more than one SharePoint server hosting SharePoint Central Administration site in the farm. I know for the fact that it's possible to have more than one server hosting SharePoint Central Administration site to provide high availability for that part of the SharePoint environment. Here is it can be done:
- Let's say you have two SharePoint servers: Server A and Server B. Server A hosts SharePoint Central Administration site, Server B doesn't
- To add SharePoint Central Administration site functionality to the Server B, run SharePoint Configuration Wizard on the Server B and at the "Completing the SharePoint Products and Technologies Configuration Wizard" step, click on Advanced Settings
- Select "Use this machine to host the website" to add SharePoint Central Administration site functionality and hit OK. Click Next to start the configuration wizard
- After the configuration wizard completes successfully, you will have additional server providing Central Administration functionality. To verify that it's in fact true, open SharePoint Central Administration site and under Farm Topology you should have Central Administration functionality listed under both servers.
If you're getting the error "The file exists. (Exception from HRESULT: 0x80070050)", when you attempt to access your SharePoint site, or even SharePoint Central Administration site, the chances are that some (or all) SIDs on your server were changed. This has probably happened because you have removed and recreated some user accounts that you use to run SharePoint services, or you have run sysprep on your server, or you have recently turned your SharePoint server into Active Directory domain controller. It's not a good idea to do any of those things with your SharePoint server, but I'm not here to judge – I'm here to help J
Please note, that the steps described below is a "low-tech" solution to the problem, which requires you to actually understand what you're about to do. USE AT YOUR OWN RISK!!! And, of course, do not forget about backups, backups, backups. Also, I would like to point out the credit for this solution goes to the blog and his/her author that is no longer online.
Anyway, to solve "The file exists. (Exception from HRESULT: 0x80070050)…" error:
- Login to your SharePoint and open SQL Server Management Studio. Create New Query
- To get the list of Site IDs you need to use SharePoint_AdminContent_* database for Central Administration Site and run the following query:
SELECT s.Id, w.FullUrl FROM Sites s inner join Webs w on s.RootWebId = w.Id
- As a result of the query above, you will see all Site IDs for the selected database. Now, using that data, run a new query:
SELECT * FROM UserInfo WHERE tp_Login='Hostname/Username' and tp_SiteID='XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'
where tp_Login is the hostname and username using which you're trying to login to SharePoint; and tp_SiteID is the site ID from the previous query
-
As a result of the query above, you will see the SID for the selected user. Now, here comes the tricky part, you need to get SID number for the user account that you're logging in with (in my case, it was Administrator account) and convert it to hexadecimal format:
- To get SID for a user account, you can use PSTOOLS utility. Run PSGETSID \\HOSTNAME USERNAME to get SID info
- To convert the SID to hexadecimal format, use the following VB script and run it against the SID obtained in the previous step: sid2gex.vbs mySID, where my mySID is the SID for the user account you're working with. As a result, you will receive SID in the hexadecimal format.
- Now we will update our database table with newly obtained SID using:
UPDATE UserInfo SET tp_SystemID = 0x010500000000000000000986BD9EA976E44036C3F5D3F04040000
FROM UserInfo
WHERE tp_ID = '1' and tp_guid='XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX' and
tp_Login='hostname\username' and tp_SiteID = 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'
where tp_ID, tp_guid, tp_Login and tp_SiteID are the attributes of the user account for which we want to update tp_SystemID. Note: you might have to repeat those steps for the services accounts which are running your search, shared services provider, etc.
After implementing the steps above, you might have to update service accounts in the SharePoint configuration. Microsoft has an excellent guide on how to make those changes.
If you need join existing SharePoint server to your Active Directory domain, then you're in for a treat. Joining the SharePoint server to the domain will mess up the authentication in SharePoint and cause errors. To join SharePoint server to the Active Directory domain without breaking SharePoint authentication:
- Back up all SharePoint content databases and all customizations that you have made to the SharePoint (stylesheets, javascript files, image files, web parts, config files, and so on)
- Uninstall SharePoint completely from the server
- Join the server to the Active Directory domain
- Reinstall SharePoint Server (make sure to use different names for content databases)
- Restore your SharePoint content databases
- Add restored content databases to the SharePoint web application(s) using "stsadm -o addcontentdb" command
- In SharePoint Central Administration >> Application Management >> Content Databases, change status of existing content databases to Offline, and set the status of the recently restored database to Ready
- Copy over the customizations that you have backed up in the beginning (stylesheets, javascript files, image files, config files, and so on) and install missing web parts, features, solutions, etc.
That should be it. Simple, right? J
If you receive "No process is on the other end of pipe…" error when you attempt to connect to the SQL Server 2005, then check if:
- SQL Server services are running
- remote connections enabled
- port settings are correct
- DNS gets resolved properly
- firewall is not preventing you from connecting successfully
- and so on and so forth…
And, if after all of these checks the error is still displayed, then the bad certificate could the one to blame. In order to be successfully loaded by SQL Server 2005, a certificate must meet all the following requirements:
- The certificate must be in either local machine or current user certificate store
- The certificate must have a good time stamp, i.e. the current system time must be in the valid time window of the certificate
- The certificate must be meant for Server Authentication
- The Certificate's key spec must include AT_KEYEXCHANGE property.
- The certificate's subject CN must match the FQDN of the server machine or the FQDN of the virtual server if the server runs on failover cluster.
If for some reason the server cannot find a valid certificate, then the server will issue a self-signed certificate to encrypt data communication between the server and client. The login packet will always be encrypted, while the data communication will be encrypted only if the server and the client are configured to do so. Anyway, to resolve the issue with the certificate, do the following:
- Open SQL Server Configuration Manager; under SQL Server Network Configuration right-click on Properties for your SQL instance, and click on Certificate tab. Then make sure that the correct and valid certificate is selected, and then reboot your SQL Server.
- If invalid certificate is explicitly specify, then remove that certificate
- Otherwise, Open Personal Store in Certificates (Local Machine and User) management console, backup all certificates in that folder and then remove all certificates from personal store
- Reboot your SQL Server
- To make sure that self-signed certificate has been loaded, open ERRORLOG file for your SQL Server and search for "A self-signed certificate was successfully loaded for encryption" line in the log file.
- Attempt to reconnect to the SQL Server
For some reason, Microsoft has decided to hide Event content type in SharePoint (MOSS/WSS) and prevent users from creating a custom list based on that content type. To unhide Event content type:
- Open your existing calendar on the site and go to List Settings
- Click on Advanced Settings and change the settings to "Allow Management of Content Types", which will reveal the Event content type in that list settings
- Click on the Event in the list of content types
- Under List Content Type Information click on the Parent link, which is strangely enough also called Event
- Under Settings click on the "Name, Description & Group" link and assign Event content type to the new group, for example "List Content Types". That's it, from now on you will be able to create custom lists based on the Event content type
There is another way to unhide Event content type, and even though I find it less graceful, I think it's worth mentioning:
- Go to [Drive]:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\ctypes\ folder and backup the contents of that folder
- To unhide Event content type, run
stsadm -o deactivatefeature -filename "ctypes\feature.xml" -url http://[SharePointWebApp]
and
stsadm -o activatefeature -filename "ctypes\feature.xml" -url http://[ SharePointWebApp]
There is an interesting bug in SharePoint Designer: sometimes when you browse SharePoint pages in the design view of the SharePoint Designer, you will see an error stating that the master page cannot be loaded. At that point you get presented with two options: either attach a different master page or work in the code view. Neither of those options actually solves the problem, they just allow you to work around it. I have never liked workarounds; I prefer solving the problems instead of working around them. J
With a little bit research I have found that the reason why my custom master page cannot be displayed in SharePoint Designer is that the default master page (default.master) has been checked out. Once I have checked in the master page, SharePoint Designer went back to displaying my master pages in the design view.
Please note that sometimes SharePoint Designer locks up the pages if you have checked out the page and then closed the application without checking in the page. So, you will have to check out the page and then check it back in. Sometimes, the only way to do is that is through the Site Content and Structure part of the SharePoint site.
Related resources:
If you're trying to export custom list template (with or without content) from one SharePoint collection or farm to the other, you might notice that your recently imported list template does not appear on the "Create Page" page of that site, which means that you cannot use the new template to create new list. This issue appears to be caused by the fact that your list definition ID of the new custom template is different
The workaround is to:
- After you have imported your template, go to List templates section (Site Actions >> Site Settings >> List Templates) and write down the Title and Feature ID fields.
- Now create new empty custom list and call it EmptyList
- Create new list template based on the EmptyList (Settings >> List Settings >> Save List as Template)
- Now when you try to create new list, you will see EmptyList on the list gallery. If you hover your mouse over the EmptyList item in the list gallery, your browser's status bar should display the URL similar to:
http://SHAREPOINT/_layouts/new.aspx?NewPageFilename=EmptyList%2Estp&FeatureId={00bfea22-ec85-4403-972d-ebe475780216 }&ListTemplate=100
- Replace the NewPageFilename and FeatureId entries with the values noted at the step one. Your new URL will look something like that:
http://SHAREPOINT/_layouts/new.aspx?NewPageFilename=ImportedListName%2Estp&FeatureId={00bfea71-de22-43b2-a848-c05709900100}&ListTemplate=100
- Copy modified URL to the address bar and hit Enter
- Configure the name and the description of the list and hit Create. Your newly created list will be based on the imported list template.
If one beautiful morning your SharePoint designers complain that they now get "The server sent a response which SharePoint Designer could not parse…" error when they try to edit SharePoint page or page layout, and/or your SharePoint developers all of the sudden are unable to access any of the SharePoint services under _vti_bin folder (like _vti_bin/lists.asmx), then check your web.config file. The tags in <httpHandlers> section in web.config file are probably out of order.
<remove verb="*" path="*.asmx" /> tag needs to be posted before any of the <add > tags in <httpHandlers> section in web.config file, otherwise the SharePoint web services path configuration breaks.
In our case this issue was caused by the web part install that incorrectly modified web.config file to configure AJAX in SharePoint. I guess the lesson is always be cautious of the automatic web part installers J
We have recently encountered a problem with some of the SharePoint (WSS or MOSS) features not working properly in Windows Vista:
- When users attempt to display a document library in the Explorer view within the web application that uses Kerberos authentication, nothing happens: Explorer view never comes up and no errors displayed either
- Or, when users attempt to display a document library within the web application that uses NTLM authentication, they get "Your client does not support opening this list with Windows Explorer" error;
- When users attempt to create list from Excel spreadsheet they get "Method 'Post' of object 'IOWSPostData' failed" error
After a lot of research and many unsuccessful attempts to fix these problems using various solutions found on the web, I have finally able to find a workaround that have worked on Windows Vista 32-bit.
Solutions that did not work in our situation:
- Installing and enabling WebDav on IIS 7
- Installing Desktop Experience on Windows 2008 server 64 bit
- Modifying EXPTOOWS.XLA macro file to force using a different version number
- Etc…
The workaround that worked:
- Install hotfix KB945015 on the client machine to fix a bug caused by an extra forward slash mark (/)appended to the query path of a WebDAV PROPFIND request
- Install Web folder hotfix on the client machine to get Vista map a drive to a web location on SharePoint
- Map a "Web Network Location" on your PC to the root of the SharePoint site in question and ensure that you save the credentials
This workaround only worked for Windows Vista 32-bit.
Related resources:
As a part of our continuing commitment to the server/service improvements and never-ending technological progress, we have moved ObjectSharp blogs to the new (better, faster, and prettier) server. ObjectSharp has always demonstrated a leadership in adopting cutting-edge technologies, so moving our blogs to the emerging cloud services only makes sense for us. For now, we use Amazon Elastic Compute Cloud running Windows, at least until Microsoft Windows Azure cloud services mature. More updates and upgrades coming soon. Stay tuned…
Please update your favorites and RSS feeds with the new URL: http://blogs.objectsharp.com
I have been working on configuring high availability for SharePoint servers (MOSS or WSS), and for a little while I wasn't able to figure out the way to modify the URL for SharePoint Central Administration site. So, basically you extend the Central Administration web application (using GUI or psconfig command) to run on multiple servers, and when you click on SharePoint Central Administration icon you're still redirected to a specific SharePoint server instead of been redirected to the Load Balancing URL. Anyway, as it turns out the URL has to be changed via registry on all SharePoint servers. Weird?!
To change the URL for SharePoint Central Administration URL:
- Open Registry editor
- Backup the registry before making any changes!!!
- Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS and change the value of CentralAdministrationURL to whatever you want to be
Related resources:
To change a port number that SharePoint Central Administration site is running on:
- Open Command Prompt
- Go to BIN folder in SharePoint install directory (by default, it would be "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN")
- To get the port number that Central Administration site is currently running on, type
stsadm.exe -o getadminport
- To change a port number that SharePoint Central Administration site is using, type
stsadm.exe -o setadminport -port <portnumber>
For a sophisticated web application, SharePoint (WSS or MOSS) is missing a feature as simple as Deny access (Deny Read, Deny Write, Deny All). To deny access to the SharePoint for single user or a group of users, you modify Policy for Web Application in SharePoint Central Administration:
- Open SharePoint Central Administration
- Click on Application Management
- Then, under Application security, click on Policy for Web Application
- Select correct web application in the drop down
- Click on Add Users
- Select web application and the zone. Click Next
- Enter the username or security group. Select Deny Write or Deny All and click on Finish
Note: This will deny access to the whole web application in SharePoint! There is no way to deny access to a specific SharePoint item (site, list, document library and so on)
Hopefully Microsoft will fix this weakness in the next service pack or so…
There appears to be a bug in SharePoint (WSS or MOSS) that breaks the backup process after extending a web application. If you need to add host headers or load balancing URL to your SharePoint web application, the only way to do that is to extend your web application (SharePoint Central Administration >> Application Management >> Create or extend Web application >> Extend an existing Web application). Even though extending web application allows you to add load balancing URL and host headers, for some reason, it breaks the backup for all site collections and sites that use that web application. You could still backup SharePoint site collection using stsadm.exe command (stsadm.exe –o backup –url http://damagedWebApp/ -filename backup_damaged_webapp.bak), but built-in SharePoint backup through Central Administration wouldn't work. You will start receiving an error (Error: Object SharePoint - 80 failed in event OnPrepareBackup. For more information, see the error log located in the backup directory. KeyNotFoundException: The given key was not present in the dictionary) every time you attempt to backup modified web application using Central Administration website.
To get backup process working again you will have to perform the following steps:
- Backup your web application database through Microsoft SQL Server Management Studio!!!
-
Detach the content database from the web application:
- Go to SharePoint Central Administration >> Application Management >> Content Databases
- Make sure to select damaged web application form the drop down list, otherwise you will messing with the wrong web application
- Click on the content database used by damaged web application
- Check "Remove content database" and click OK (ignore the warning). Removing the content database does not delete the database; it only removes the association of the database with the Web application. This action is analogous to detaching a database in SQL Server in that the content of the database remains intact.
-
Delete the web application (remove SharePoint from it):
- Go to SharePoint Central Administration >> Application Management >> Delete Web Application
- Make sure to select damaged web application form the drop down list
- Leave "Delete Content Databases" and "Delete IIS Websites" options set to "No". You can always remove them later, right now we are only interested in removing SharePoint references to the damaged web application
-
Create a new web application with the appropriate settings for host header, load balancing URL and so on:
- Go to SharePoint Central Administration >> Application Management >> Create or extend Web application >> Create new Web application
- Configure new web application settings. Don't forget host headers, new website and port settings, and load balancing URL (as needed) and click OK
- Remove content database of the newly created web application by running
stsadm.exe -o deletecontentdb -url http://newwebapplication:port -databasename NEW_WEBAPP_DB
Go to http://technet.microsoft.com/en-us/library/cc262449.aspx for more information on deletecontentdb operation of stsadm.exe command
- Attach the existing database to the new web application by running
stsadm.exe -o addcontentdb -url http://newwebapplication:port -databasename OLD_WEBAPP_DB
Go to http://technet.microsoft.com/en-us/library/cc263422.aspx for more information on addcontentdb operation of stsadm.exe command
- Make sure that host headers in IIS as well as Alternate Access Mapping is set properly and try running the full SharePoint backup again through Central Administration.
After those steps you will probably also have to configure search server setting for your content database (SharePoint Central Administration >> Application Management >> Content Databases >> Select Search Server from drop-down list) and get full crawl running to make sure that your search is up-to-date and working properly.
Now that your backup is running again, it should safe to remove:
- the database that was created with new web application (see Step 5 above)
- the website used by damaged web application (assuming you don't need this website for anything else)
Related resources:
Before I start writing how to set up Kerberos authentication in SharePoint, let me explain our set up a little bit, i.e. server names, account names and so on that will be used in this guide:
WSSSERVER1 – SharePoint web front server
WSSSERVER2 – another web front server (optional)
DBSERVER1 – database server running Microsoft SQL Server 2005 SP2
Domain\wss_srvc_account – User account used to run SharePoint services
Domain\sql_srvc_account – User account used to run SQL services on database server
Domain\wss_apppool – User account used to run SharePoint web application pool
Domain\mysite_apppool – User account used to run My Site web application pool
Domain\sspadmin_apppool – User account used to run Shared Services Provider web application pool
To set up a Kerberos authentication in SharePoint (WSS or MOSS) you need to do a bunch of small configuration changes:
- Make sure that you have host headers set up for your SharePoint sites. For example, in case of Windows SharePoint Services you will have only the main SharePoint website, whereas in case of Microsoft Office SharePoint Server 2007 you will have main SharePoint website, My Site website, and Shared Services Provider Sites. For the sake of simplicity, let's call those host headers: http://sharepoint, http://mysite, http://sspadmin respectively.
-
Update Alternate Access Mappings to point websites to website host headers. In other words, replace http://servername:2222 entry with
http://sharepoint
-
Add SPN records for:
- Hostnames and FQDN of computer account(s) of your SharePoint server(s), for example
Setspn.exe -A HTTP/WSSSERVER1 DOMAIN\wss_ srvc_account
Setspn.exe -A HTTP/WSSSERVER1.domain.local DOMAIN\wss_srvc_account
Setspn.exe -A HTTP/WSSSERVER2 DOMAIN\wss_ srvc_account
Setspn.exe -A HTTP/WSSSERVER2.domain.local DOMAIN\wss_srvc_account
- Hostnames and FQDN of computer account of your SQL server, for example
Setspn.exe -A MSSQLSvc /DBSERVER1:1433 DOMAIN\sql_srvc_account
Setspn.exe -A MSSQLSvc /DBSERVER1.domain.local:1433 DOMAIN\ sql_srvc_account
-
Host headers for your SharePoint websites, for example
Setspn.exe -A HTTP/INTRANET DOMAIN\wss_apppool
Setspn.exe -A HTTP/ INTRANET. domain.local DOMAIN\wss_apppool
Setspn.exe -A HTTP/MYSITE DOMAIN\mysite_apppool (Do not apply in case of WSS)
Setspn.exe -A HTTP/MYSITE. domain.local DOMAIN\mysite_apppool (Do not apply in case of WSS)
Setspn.exe -A HTTP/SSPADMIN DOMAIN\sspadmin_apppool (Do not apply in case of WSS)
Setspn.exe -A HTTP/SSPADMIN. domain.local DOMAIN\sspadmin_apppool (Do not apply in case of WSS)
-
Configure "Trust for Delegation" on all computer accounts and user accounts used in SharePoint configuration. To configure "Trust for delegation":
- Open Active Directory Users and Computers management console
- Right click on a user or computer account that require ""Trust for Delegation" configured and click on Properties
-
Where you find this option in the GUI depends on the Active Directory functional level. In case of Windows 2000 domain, the option is under Account tab for user accounts and General tab for computer accounts. In case of Windows 2003 domain, the option is under a separate Delegation tab. Note: Delegation tab is only visible for accounts that have SPNs registered
-
Configure Component Services to allow Local Launch and Activation permissions for IIS WAMREG Admin Service for all application pool accounts used in SharePoint configuration. To configure Component Services setting go Control Panel >> Component Services >> Computers >> My Computer >> DCOM Config >> properties of the "IIS WAMReg Admin Service" >> Security tab >> edit "Launch and Activate Permissions" >> add "Local Launch" and "Local Activation" permissions for all the application pool accounts
-
Because in IIS7 HTTP.sys is handling the authentication, it is by default done under the LocalSystem account regardless of the application pool account you're using. However, because even a single SharePoint server configuration is now considered a web farm, we should use a domain account to run SharePoint application pools. As a result we need to modify applicationhost.config file to configure the useAppPoolCredentials attribute in system.webServer/security/authentication/Windows-Authentication configuration section to true.
<windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true"/>
-
Once you have made a change to applicationhost.config file you might start getting errors 6398, 7076, 6482 in your Event Viewer. To get rid of those errors you need to apply hotfix KB946517. This hotfix is currently is available for Windows Server 2003, XP and Vista and it is under development for Windows Server 2008. I have used Vista version of the hotfix on Windows Server 2008 and it seems to have worked fine (knocking on wood...)
-
Now you're ready to switch your SharePoint web applications to Kerberos authentication. Open SharePoint Central Administration >> Application Management >> Authentication Providers >> choose your web application >> change authentication to Negotiate (Kerberos)
- In case of MOSS, to change your Shared Services Provider web application to use Kerberos authentication run the command: stsadm.exe -o SetSharedWebServiceAuthn –negotiate. Stsadm.exe is usually placed under C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin.
That's it, you should now have your web applications using more secure Kerberos authentication. You can use Fiddler (http://www.fiddlertool.com/Fiddler2/version.asp) to verify that your web application is in fact using Kerberos authentication. Here are a few links that will help you might find useful:
Related resources:
It's been a while since I blogged about something. Maybe it's because I've been busy lately, maybe it's because of I've spent a week at the TechEd conference (the best conference ever, by the way) and a week working on my tan at Daytona Beach, or maybe it's because I'm just getting old and lazy. But I digress...
I have recently had the "pleasure" of installing Microsoft Exchange 2007 SP1 on a virtual server running Windows Server 2008. I was eager to try Microsoft's latest and greatest product. Originally I wanted to install it on Microsoft Virtual Server, but unfortunately MS Virtual Server doesn't support 64-bit virtual servers on a 32-bit host server! So, to get virtual server running, I had to rebuild the physical server, which makes no sense to me whatsoever. Since I was willing to do that, I had no choice but to go with VMWare Virtual Server which fully supports 64-bit virtual servers on a 32-bit host server. VMWare's product turned out to be an excellent product with tons of easy to use features. Hopefully, Microsoft's product will soon catch up.
Usually, I would never recommend running Exchange 2007 virtually in the production environment, unless you have a kick-a$$ host server to run it or if you have fewer than 50 mailboxes. But if you have to - or want to - run Exchange 2007 on VMWare Virtual Server, you need to know that Microsoft does not support this scenario. Even though for the most part it runs fine, there is a problem with the way VMWare virtual adapters work with IP6, which causes the problem with Outlook Anywhere connectivity.
Fortunately, there is a great article on Microsoft Exchange Team blog that helps you to deal with that problem: http://msexchangeteam.com/archive/2008/06/20/449053.aspx . Essentially, you need to turn off IP6 on your Exchange server NIC configuration and in the hosts.conf file. You also need to make sure that your Exchange server can talk to Global Catalogue servers by configuring RPCProxy port in the registry.
There is also a great online tool from Microsoft that helps you troubleshoot any connectivity issues with Exchange 2007/2003: https://www.testexchangeconnectivity.com/
In conclusion, kudos to VMWare for the great product, and kudos to Microsoft for their detailed documentation to get things working, as well as providing great online tools for troubleshooting.
If you plan to convert your physical domain controllers into virtual servers, you probably know there is a lot to consider prior to the move. But what you might not know is that Active Directory doesn't like being restored from the image, which what all physical-to-virtual conversion tools (Acronis, Ghost, etc.) are doing. It doesn't matter if you are trying to convert your physical server to a virtual or if you're converting your server from one virtual format to another (for example, Vmware-to-VPC, or vice versa).
After the conversion, replication process breaks and the error starts appearing in the log files "The source server is currently rejecting replication requests"; the same error pops up when you try to run dcpromo command. Obviously if the problem is not resolved within 60 days, that domain controller will get tombstoned by Active Directory, which is not very good. Most of the websites suggest to forcibly remove that domain controller from the Active Directory by running dcpromo / forceremoval and then cleaning up your schema using metadatacleanup of ntdsutil. To me this solution is not only too drastic, but often is not an option because it might cause more problems than it will resolve.
After an extensive research I have finally found a solution that has worked for me. The solution is actually pretty simple: you simply need to enable inbound and outbound replication on the "faulty" domain controller.
To enable inbound replication, run:
repadmin /options SERVERNAME -disable_inbound_repl
To enable outbound replication, run:
repadmin /options SERVERNAME -disable_outbound_repl
And the error disappears J
To get more detailed messages in MOSS 2007 and WSS3.0 during development process, user can enable debugging in the web.config file for the SharePoint web application:
<SafeMode
MaxControls="200"
CallStack="true"
DirectFileDependencies="10"
TotalFileDependencies="50"
AllowPageLevelTrace="false">
And:
<customErrors
mode="Off" />
This should make development process so much pleasant and more efficient, by getting rid of "An unexpected error has occurred" error, which is useless to the developers.
Note: It's not recommended to have debugging enabled on the production server, if possible, please do all your debugging on the development server(s)
I recently discovered that piping can be used in conjunction with STSADM command. I always found it difficult to use that command. It has too many options and parameters that are not always obvious and often very difficult to use. Piping makes it easier to use STSADM command, it can be used for search through STSADM keywords in the commands: For example, stsadm | find "enum" can be used to find all STSADM keywords related to enumeration within SharePoint. Or, you can also use pipe | more to paginate the STSADM output, which could be very useful.
You can also redirect STSADM output using the redirecting command: stsadm > filename >& This can be very helpful when you need to generate an output and view it later, or if you need to export that output into a different application.
I realize it's very basic, but it's the basic things like this that help me save time and keep my sanity.
If you have recently re-attached your content database to the new web application in SharePoint 2007 (whether because you have moved your SharePoint install or simply because you had to re-create the web application on your current server), you might have noticed a new error (Event ID: 5555; Event Source: Office SharePoint Server) occurring hourly in the Event Log of your web-front SharePoint server.
The description of the error tells you to run stsadm – o preparetomove, which doesn't seem to fix the problem, unfortunately. This command only prevents the error 5555, if you run it before moving and re-attaching your content databases. To fix error 5555, you need to run stsadm –o sync instead.
In my case, running the following command made error 5555 disappear:
stsadm -o sync -DeleteOldDatabases 0
As usual: ALWAYS BACKUP YOUR SHAREPOINT BEFORE MAKING ANY CHANGES TO ITS CONFIGURATION
Today was my one year anniversary in my new job as an IT Manager at ObjectSharp. It's been an interesting year; a year full of new experiences and surprises, mostly good ones.
One year ago I have traded a job at a public sector for one in a private sector. I have traded a stable and secure environment with clear guidelines, managerial or supervision rules and specific working times for a more open managerial style, openness to new ideas and more flexibility in rules with fewer guidelines. And, honestly, I have no regrets so far. After a year, I'm having more fun than ever. It's fascinating working with a team of exceptional people from a range of disciplines whose commitment to excellence is steadfast. At ObjectSharp, I got a chance to work with the newest and coolest technologies from Microsoft (often even before those technologies were available to the general public.) Here, I am working with a talented team of professionals who not only know how to get those technologies to work, but they know how to make them work better and more efficient. I love it!
On sad note, today I was expecting balloons, hugs, high fives, or even just a disgusted "I can't believe your still here". Nothing. Well, there is still time... ;)
Note: Later that day I did get a few high fives, no balloons though J
Apparently there is a limit on a number of controls you can have on a SharePoint page. By default, no more than 200 controls are allowed on the SharePoint page. Not sure, why this limitation is there, but it is. To get around this problem, you need to increase the MaxControls setting in your web.config file:
<SafeMode
MaxControls="200"
CallStack="false"
DirectFileDependencies="10"
TotalFileDependencies="50"
AllowPageLevelTrace="false">
<PageParserPaths>
</PageParserPaths>
</SafeMode>
In my case, I have MaxControls parameter set to 300.
Team System Web Access 2008 SP1 CTP (Community Technology Preview) and Work Item Web Access 2008 CTP are now available for download. Even though it's only CTP version at the moment, don't let it discourage from using it, because it seems to be working very well. By the way, you still have to have Team Explorer 2008 installed to use TWSA and/or WIWA, which is not a big deal since it's free and most of us already have it installed anyway. For those who don't have Team Explorer 2008 installed, it can be downloaded for free from http://www.microsoft.com/Downloads/details.aspx?familyid=0ED12659-3D41-4420-BBB0-A46E51BFCA86&displaylang=en.
Team System Web Access 2008 SP1 has some really great features:
- Single instance with multiple languages (9 languages are available: ENU, CHS, CHT, DEU, ESN, FRA, ITA, JPN, KOR)
- Support for specifying field values in the URL for creating new work items (works in both TSWA and WIWA)
- Share ad-hoc work item queries
- Shelveset viewer
- Improved search support
Team System Work Item Web Access 2008 CTP allows users to use some work item tracking feature without having TFS client access license (CAL.) A user without TFS CAL can use WIWA to:
- Create new work items
- Edit the work item you have created
- See the list of work items you have created
However, user cannot:
- See work items created by others
- List, view, edit or run work item queries
- Add, edit or remove work item links (except attachments and hyperlinks)
- Access documents stored on the project portal
- Access project reports
- Access source control
- Access team build
Specs for WIWA can be found at http://msdn2.microsoft.com/en-us/teamsystem/bb936702.aspx
When you have a public-facing site built using SharePoint technologies, opening Microsoft Office documents (Word, Excel, PowerPoint, Visio, etc.) stored on this website requires user to login. You can hit Cancel at the login prompt and still be able to see the document, but having a login prompt displayed to the Internet users, sort of defeats the purpose of having SharePoint-built public facing website with anonymous access turned on. This happens becuase Microsoft Office is closely integrated with MOSS or WSS 3.0 now, and MS Office is now able to recognize that the document is stored within SharePoint, so the appropriate SharePoint authentication/authorization tools kick in. This problem can be resolved mostly by implementing two simple steps (assuming you have already enabled anonymous access on SharePoint):
- Disable 'Client Integration' for the web application under Central Admin Home Page >> Application Management >> Authentication Providers
- Remove the OPTIONS verb from the <HTTPHandlers> registration line in web.config file
Related resources:
To enable anonymous access for a web application within SharePoint:
1. Go to Central Administration >> Application Management >> Authentication Providers.
- make sure to pick correct web application from the drop-down list at the top-right corner of the page.
- select the Membership Provider (most likely it will be "Default") and enable check "Enable anonymous access" checkbox.
- click OK to save the settings.
2. The step above will usually enable anonymous access in IIS Manager, but just be sure:
- open IIS Manager
- right-click on your website and click on "Edit" under Authentication and Access Control
- make sure "Enable anonymous access" is checked
3. We now need to explicitly enable anonymous access on our website(s)
- browse to the website
- click Site Actions >> Site Settings >> People and Groups >> Site Permissions
- click on Settings >Anonymous Access and enable anonymous access for the site
* Anonymous access will be also enabled on all subsites that inherit security settings from the parent site.
Related resources:
I have found a very interesting article on Technet on how open source community has influenced Windows Server 2008. I think it is very encouraging that Microsoft is taking user’s feedback seriously and trying to integrating the improvements developed by open source community into its system. And, if they make a few bucks along the way by doing this, so be it.
One has to admit, there's no better enterprise level system then Windows server. Not yet, anyway. It's streamlined and well designed; it's an excellent tool for desktop and user support/control (OUs and policies). Exchange, ISA, WSUS, and many others integrate naturally into AD. It is about what public knows the best, at work, at home, and in the library. As much as I love Linux, it's not even close to being there. It's all dispersed, scattered-around collection of technology DIY's, that works, but has no core. For those who want to learn more about Windows Server 2008 and, as I am, are too lazy to read a book, here are some clear installation instructions from TrainSignal:
http://www.trainsignaltraining.com/w...on/2008-02-28/
It will be interesting to see a similar lists for other Microsoft products, such as Office, SQL Server or Visual Studio.
Recently I tried to install SQL Server 2005 on Windows Vista and I have received a warning message for IIS Feature requirement on the System Configuration Check page of the SQL Server 2005 Setup program. This means that you won’t be able to install SQL Server components, requiring IIS, such as Reporting Services. The problems occurs because IIS 7.0 is much more customizable and has much more components, so some of the components required for RS installation are missing from the default IIS 7.0 install. Here is the list of the IIS components required for Reporting Services:
|
Component |
Folder |
|
Static Content |
Common HTTP Features |
|
Default Document |
Common HTTP Features |
|
HTTP Redirection |
Common HTTP Features |
|
Directory Browsing |
Common HTTP Features |
|
ASP.Net |
Application Development |
|
ISAPI Extension |
Application Development |
|
ISAPI Filters |
Application Development |
|
Windows Authentication |
Security |
|
IIS Metabase |
Management Tools |
|
IIS 6 WMI |
Management Tools |
For instructions on how to install missing IIS components in Windows Vista, go to: http://www.iis.net/default.aspx?tabid=2&subtabid=25&i=957 (http://www.iis.net/default.aspx?tabid=2&subtabid=25&i=957).
For instructions on how to install missing IIS components in a Server Core installation of Windows Server 2008, go to: http://www.iis.net/default.aspx?tabid=2&subtabid=25&i=956
The solution is also explained in Microsoft KB920201.
Microsoft has made quite a few changes to reports in TFS 2008. As you can see form the table below in TFS 2008 we do not only have 6 new reports, but some of the existing reports have been modified/removed (new reports are in red, removed reports are in orange).
TFS 2005 default reports | TFS 2008 default reports |
Actual Quality vs Planned Velocity
Bug Rates
Bugs by Priority
Bugs Found Without Corresponding Tests
Builds
Load Test Summary
Project Velocity
Quality Indicators
Reactivations
Regressions
Related Work Items
Remaining Work
Scenario Details
Tests Failing Without Active Bugs
Tests Passing With Active Bugs
Unplanned Work
| Actual Quality vs Planned Velocity
Bug Rates
Bugs by Priority
Bugs Found Without Corresponding Tests
Builds
Exit Criteria
Issues List
Load Test Detail
Load Test Summary
Project Velocity
Quality Indicators
Reactivations
Regressions
Related Work Items
Remaining Work
Scenario Details
Tests Failing Without Active Bugs
Tests Passing With Active Bugs
Unplanned Work
Work Item with Tasks
Work Item with TestResults
Work Items
|
This means that when you upgrade/migrate to Team Foundation Server 2008, your reports will no longer work as the schema has changed. To resolve the issue you need to download the new process template (http://msdn2.microsoft.com/en-us/teamsystem/aa718795.aspx) and add or update your reports on TFS server.
To add new report:
- Go to your Reports server (http:// [SERVERNAME] /reports)
- Click on Upload file
- Browse to the report file (.rdl) you want to upload and click OK to upload
- Click on newly uploaded report file and click on Properties
- Set up data sources by clicking on Data Sources (Don't forget to click Apply button)
- Depending on report, you might also have to set up default parameters by clicking on Parameters (Don't forget to click Apply button)
- Click on View to make sure that report is displaying properly
To update existing report:
- Go to your Reports server (http:// [SERVERNAME] /reports)
- Click on report that you want to update and click on Properties
- Click on Update
- Browse to the report file (.rdl) you want to upload and click OK to upload
- Make sure that data sources are configured properly by clicking on Data Sources (Don't forget to click Apply button)
- Depending on report, you might also have to set up default parameters by clicking on Parameters (Don't forget to click Apply button)
- Click on View to make sure that report is displaying properly
Note: You will have to update reports for each TFS project
If you have recently moved your SharePoint site (WSS 3.0 or MOSS 2007) from one hardware to another using backup/restore procedure, you might have noticed a few missing timer jobs definitions: Scheduled Approval, Scheduled Page Review, Scheduled Unpublish, Variations Propagate Page Job Definition, and Variations Propagate Site Job Definition. In our case, we had multilingual SharePoint site that stopped propagating variations after SharePoint move, so the content created in one language was not re-created in another. Very frustrating…
After looking into the problem, I discovered that SharePoint does not restore those timer job definitions by default. Naturally, not having those jobs will cause problems with scheduled publishing as well as variations propagation. To get those timer job definitions back on the list and running again, you will have cheat a little by creating a new site collection using Publishing Portal or Collaboration Portal templates. Creating new site collection using Publishing Portal or Collaboration Portal templates will force SharePoint to create missing timer job definitions. New site collection can be removed shortly after created.
Note: Changes made in variations since the SharePoint move might take while to propagate. To expedite the propagation you can manually force the variations update.
Users of Microsoft Windows Vista and Office 2007 might have encountered an error "Unknown error trying to lock file" when they click Edit Document. This error however didn't occur for users of Microsoft XP with Office 2007. As far as I know the problem occurred because of the changes made in the Web Client service in Vista and the way Office was communicating with Sharepoint. Installing Microsoft hotfix 943280 and patching your Web Folders with 907306 didn't resolve the problem. Trying numerous workarounds described on the web didn't resolve the problem either. The only workaround that worked setting the office applications to run in "Windows XP SP2 compatibility mode", but then why would you run Windows Vista. You could say this is another reason to go back old Windows XP.
Luckily with the release of SP1 for Vista this problem disappears! So, thank you Microsoft for solving this problem, although I hope such problems will be resolved faster and more efficiently. I would wish that those problems will not exist in the first place, but then I start thinking that if all software would run smoothly, it will make a life of IT guys pretty boring. So, thank you Microsoft for keeping IT guys busy/employed! J
Note: Don't forget to upgrade your SharePoint servers to SP1.
Related resources:
If you have a public Sharepoint site (MOSS 2007 or WSS 3.0) that is accessible to anonymous users and you’re not using custom scopes, you probably already noticed that every time users try to search they get a user prompt. To get pass this prompt you must enter valid username, otherwise you’ll get famous “Access Denied” page. So much for anonymous access, right?
Anyway, the problem is with OSSSearchResults.aspx page, specifically with one of the inheritance reference that ASPX page. I’m talking about the part of the code that sets the inheritance of the page from the generic application page base class, which is not really required for this page to function properly.
To allow anonymous users to search your publicly available sites you need to remove that inheritance from the code, so find part of the code inside the <Page> tag that states “Inherits="Microsoft.SharePoint.WebControls.LayoutsPageBase" and remove that part of the code (not the whole line, just the part that inhertis the application page base.) OSSSearchResults.aspx page is usually stored at C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS on your SharePoint server. Make sure you backup the file before making any changes!
Making those changes will not only allow anonymous users to search the SharePoint content, but also will keep the SharePoint search secure, meaning that anonymous users will only be able to search the part of the SharePoint they have permissions to view.
Related resources:
First of all, you must backup SharePoint. Upgrading to SP1 should not break your WSS3/MOSS2007 install, but it's always better to be safe than sorry.
In my case we have 32-bit installation of SharePoint server, so these guidelines will refer to 32-bit version of SP1 for WSS3/MOSS2007, but as far as I know the guidelines can also be used for installation of SP1 on 64-bit instances of SharePoint server (just make sure you download 64-bit version of Service Pack file). You can download Service Pack 1 from Microsoft website (For MOSS installations, Service Pack 1 for both WSS3 and MOSS2007 must be installed):
- Windows SharePoint Services 3.0 Service Pack 1 (27.3Mb)
- Microsoft Office SharePoint Server 2007 Service Pack 1 (78.9Mb)
Now that you've backed up your SharePoint install and downloaded the updates, you're ready to install the service pack. First, let's install Service Pack 1 for WSS3:
-
Stop the World Wide Web Publishing Services
- Go to Start >> Administrative Tools >> Services
- Select World Wide Web Publishing Service and click Stop
-
Install the Windows SharePoint Services Service Pack 1
- Run the downloaded executable file WSS3 SP1 (wssv3sp1-kb936988-x86-fullfile-en-us.exe)
- Accept the licensing terms. Technically you should read the EULA terms before accepting, but nobody I know actually does it, so...
- Click Continue and click OK when prompted to remind the administrator to update all SharePoint servers.
- Click OK when the installation completes.
- If you have MOSS2007 installed then skip SharePoint Configuration Wizard (i.e. close it, if prompted) and proceed to installing SP1 for MOSS 2007. If, however, you only have WSS3 installed, then run SharePoint Configuration Wizard, start World Wide Web Publishing Service and that's it.
Second, if you have MOSS2007, we need to install SP1 for MOSS2007:
-
Install the Microsoft Office SharePoint Server Service Pack 1
- Run the downloaded executable file (officeserver2007sp1-kb936984-x86-fullfile-en-us.exe)
- Accept the licensing terms. Technically you should read the EULA terms before accepting, but nobody I know actually does it, so...
- Click Continue and click OK when prompted to remind administrator that you update all SharePoint servers.
- Click OK when the installation completes.
-
Run SharePoint Configuration Wizard
- If SharePoint Configuration Wizard won't run automatically after SP1 install go to Start >> All Programs >> Microsoft Office Server >> SharePoint Product and Technologies Configuration Wizard
- Click Next at the Welcome screen and click Yes when prompted with the warning about restarting services
- Click Next at the Completing the SharePoint Product and Technologies Configuration Wizard and click OK when prompted to remind the administrator to update all SharePoint servers
- Go get a cup of coffee because the wizard might take a while to complete
- Click Finish after the configuration completed
-
Start World Wide Web Publishing Service to make your SharePoint server accessible by users again
- Go to Start >> Administrative Tools >> Services
- Select World Wide Web Publishing Service and click Start
If you want to make sure that you have successfully updated your WSS3 or MOSS2007 to Service Pack 1 you can do that through SharePoint Central Administration or Add/Remove Programs. To verify the SharePoint version through SharePoint Central Administration:
- Open SharePoint Central Administration, go to Operations tab
- Under Topologies and Services section click Servers in farm to list your SharePoint server(s)
- If you see "Version: 12.0.0.6219" next to your SharePoint server, then you have successfully upgraded that server to Service Pack 1.
Alternatively, you can verify the SharePoint version through Add/Remove Programs in Control Panel:
- Go to Start >> Control Panel >> Add/Remove Programs
- Select Microsoft Office SharePoint Server and click on "Click here for support information"
- If you see "Version: 12.0.0.6219", then you have successfully upgraded that server to Service Pack 1.
Please note that if you have multiple SharePoint Servers (WSS3 and/or MOSS2007) you need to update all of them to Service Pack 1!!!
Related resources:
If you're thinking about migrating WSS 3.0 or MOSS 2007 sites to a new server, you need to remember to reinstall any third-party webparts you have installed on the old Sharepoint server. So if your Sharepoint instance have Reporting Services webpart installed you will have to re-install it, but before you do that make sure you remove old webpart from the Web Part Gallery and remove (or comment out) any references to the old RS webpart from web.config file in the Sharepoint's virtual directory.
<SafeControl Assembly="Microsoft.ReportingServices.SharePoint.UI.ServerPages, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" Namespace="Microsoft.ReportingServices.SharePoint.UI" TypeName="*" Safe="True" />
<SafeControl Assembly="Microsoft.ReportingServices.SharePoint.UI.WebParts, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" Namespace="Microsoft.ReportingServices.SharePoint.UI.WebParts" TypeName="*" Safe="True" />
<SafeControl Assembly="RSWebParts, Version=8.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" Namespace="Microsoft.ReportingServices.SharePoint.UI.WebParts" TypeName="*" Safe="True" />
<add verb="*" path="Reserved.ReportViewerWebControl.axd" type="Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<add verb="*" path="_vti_bin/ReportServer" type="Microsoft.ReportingServices.SharePoint.Soap.RSProxyHttpHandler, RSSharePointSoapProxy, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" />
<add verb="*" path="Reserved.ReportViewerWebPart.axd" type="Microsoft.ReportingServices.SharePoint.UI.WebParts.WebPartHttpHandler, Microsoft.ReportingServices.SharePoint.UI.WebParts, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" />
<location path="_vti_bin/ReportServer/ReportServiceAuthentication.asmx">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
Note: If you don't remove the references to the old RS webparts, you won't be able to get reports to display properly no matter how many times you re-install the webpart.
To install TFS you must have Sharepoint Services 2.0 installed on the same server. Even though there hacks that allow you to integrate TFS with Sharepoint 3.0 that could be installed on another server, there still certain restrictions in place. One of them is Sharepoint naming conventions for when you install TFS:
Application Pool Name: TFSWSS (use TFSSERVICE account)
Application Pool Name: TFSWSSADMIN (use TFSSERVICE account)
Configuration Database Name: STS_Config_TFS
Content Database Name: STS_Content_TFS
Username to use: TFSSERVICE account
You can change those names later on though. Hopefully this issue will be addressed in Orcas…
If you use SQL 2005 Express Edition/MSDE/SSEE with your installation of Sharepoint, CRM or whatever, when you decide to uninstall those products SQL 2005 Express Edition will not be uninstalled. So, you will end up with "orphaned" copy SQL 2005 Express Edition, which will prevent you from installing any other applications that use it.
To uninstall SQL 2005 Express Edition:
- Open Registry and go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall.
- Browse through the entries and find the one that says "Microsoft SQL Server 2005 Express Edition" or something like that
- Copy the value of UninstallString into clipboard (Ctrl-C). Example of UninstallString value is "MsiExec.exe /X{6E740973-8E71-42F9-A910-C18452E60450}"
- Open Command Prompt
Paste the command from clipboard and add "CALLERID=OCSETUP" at the end of the command and hit Enter. This will run an Uninstall Wizard, which will help you to uninstall SQL Server 2005 Express Edition
Example of the uninstall command: MsiExec.exe /X{6E740973-8E71-42F9-A910-C18452E60450} CALLERID=OCSETUP
We used to get a timeout error every time we tried to upload files larger than 48Kb to TFS. The timeout error was caused by one of numerous IIS hidden settings, i.e. UploadReadAheadSize parameter in IIS. Because this parameter is not set by default, IIS uses the default schema value of 48Kb.
To allow larger files to be uploaded to TFS, we had to change this parameter to a larger value (in our case I've set it to 10Mb). Here is how it's done:
- Open Command Prompt
- Go to your Inetpub\adminscripts folder
- Type in adsutil get w3svc/UploadReadAheadSize to check your current setting
- To change this parameter, type in adsutil set w3svc/UploadReadAheadSize SIZE_IN_BYTES. For example to set this parameter to 10Mb use "10000000" as the size
- Type in adsutil get w3svc/UploadReadAheadSize again to make sure that the parameter has been changed
Since, it's my first post I thought that I should start with something simple yet very frustrating. For about a week we had a problem with our TFS server. Occasionally users were not able to login to TFS server using Team Explorer for no apparent reason. After numerous attempts to find the cause of all this problems, the solution turned out to be pretty simple. There was a time synchronization problem between TFS server and Time Server on the network (which in our case was one of domain controllers).
To resolve I have set up TFS server to sync time with the domain controller and set a domain controller to sync time with one of the public time servers on the Internet. To me, it's always better to have all your servers to synchronize their time settings with one of the internal server and only that internal server would synchronize with external time servers, instead of all servers synchronizing with external servers. Here is how it can be done:
ON TFS SERVER:
- Make sure that you have Windows Time service running and set to Automatic start-up on TFS Server
- To check whether your time service is set, type NET TIME in Command Prompt:
net time /domain:DOMAINNAME
- If no time servers have been set, use NET TIME command to set up the time server:
net time /setsntp:DOMAINCONTROLLER
ON DOMAIN CONTROLLER:
- Make sure that you have Windows Time service running and set to Automatic start-up on Domain Controller
- To check whether your time service is set, type NET TIME in Command Prompt:
net time /domain:DOMAINNAME
- If no time servers have been set, use NET TIME command to set up the time server for Domain Controller:
net time /setsntp:PUBLICTIMESERVER
For the list of the Simple Network Time Protocol (SNTP) time servers that are available on the Internet go to http://support.microsoft.com/default.aspx/kb/262680
After I have set up the time synchronization, our TFS server has been running smoothly ever since (knocking-on-the-wood)...