Tommy Segoro

INTRODUCTION

Sharepoint VNext 2010 is coming up so I have to make sure that CompleteSharepoint.NET – the content management system built on top of WSS 3.0 (http://www.completesharepoint.net) – is compatible.

So I run stsadm -o preupgradecheck and below is the results:

Luckily CS.NET is vNext 2010 compatible! WOOHOO! Please note though that I ran this on a Windows Server 2008 x64 bit environment. Sharepoint vNext 2010 only works on a x64 bit environment and to be precise, it can only run on IIS version 7 onwards. Windows Server 2003 will not be supported.

Your SQL Server has to be x64 bit as well. It has to be SQL 2005 onwards.

Below is the results from the HTML report:

==

There are other text in the report which I haven't included in this article but the main thing is, I didn't get any error message in the report. Some of the elements (such as custom field types) won't be upgraded automatically (ie. need to be upgraded manually).

==

Therefore, if you have used CompleteSharepoint.NET for your client website you'll be able to upgrade to the next version of Sharepoint when it arrives.

I'll keep you posted about the upgrade process.

Cheers and please stay tuned,
Tommy

INTRODUCTION

Hi everyone, a client has been using CompleteSharepoint.NET as their website framework.

If you're interested, please go to http://www.attadalechiropractic.com. They're chiropractor based in Attadale, Western Australia.

The features of the website are:
- Random quote generated from a Sharepoint list
- Custom navigation controls
- The use of CompleteSharepoint.NET custom sitemap provider

If you're interested in using CompleteSharepoint.NET for your personal and clients' website, please go to http://www.completesharepoint.net.

Some other websites that have been using CS.NET:
- http://www.bmuu.com.au
- http://www.tommyfrancesca.com
- http://www.completesharepoint.net

Cheers,
Tommy

INTRODUCTION

The client I'm currently working has the following farm configuration:
- 1 WFE
- 1 Central Admin + Indexing
- 1 DB

They have both Test and Prod environments configured with the same number of servers.

After a while, the client starts to find out that although User Profile Import service is running successfully nightly and the data is updated correctly from AD, but somehow the WSS Profile Page is not updated with the latest AD data. There is someone whose job title is updated in AD and it hasn't been replicated in WSS Profile Page although this person's My Site page and search results page are already updated with the correct data. This problem happens in both Test and Prod.

After a day worth of investigation I found out that the secure certificate for Office Server Web Services web site needs updating.

Below are some of the warnings in Event Viewer:

==

Microsoft.Office.Server.UserProfiles.UserProfileException: Failed to obtain crawl status. —> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. —> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

==

WHAT DOES IT CAUSE?

With MOSS there are two profile "area" that needs to be updated, MOSS Profile and WSS Profile page.

My Sites and search results page are displaying information from MOSS Profile Page but Contact Details web-part and People And Groups -> All People display information from WSS Profile Page.

Because of this issue, the WSS Profile Page is not updated and causing Contact Details web-part to display incorrect (old) information about someone's profile.

HOW DO YOU SOLVE IT?

After reading some blogs about the error, I finally came up with a solution:

1. Use SelfSSL to update Office Server Web Services web site. Run the following command:
selfssl /S:<site ID of Office Web Services – mine is 951338967> /V:999999

2. Perform full User Profile import in SSP

3. Run stsadm -o sync -deleteolddatabases 0 –> This is to remove the failed-to-sync database information (don't worry it's safe. It's not deleting the actual content database or anything like that)

3. Run stsadm -o sync -sweeptiming m:2 -synctiming m:3 –> This is to sync the WSS Profile Page every 2 minutes, we'll change this later to every day or every 12 hours once we've known that we've solved the problem.

4. Wait for 2-3 minutes.

5. Open Event Viewer and you shouldn't see any more of the above warnings.

6. Go to Central Admin -> Operations -> Timer Job Status -> Profile Synchronization and Quick Profile Synchronization, they will run successfully.

7. DONE, run stsadm -o sync -sweeptiming h:12 -synctiming h:12 –> To set the WSS Profile Update every 12 hours.

That's it.

Hope this helps,
Tommy

Microsoft.Office.Server.UserProfiles.UserProfileException: Failed to obtain crawl status. —> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. —> System.IO.IOException: Authentication failed because the remote party has closed the transport stream.

INTRODUCTION

This is a series:
- Managing Risks in Sharepoint 1 – Aligning the Environments
- Managing Risks in Sharepoint 2 – User Permissions

In the previous articles I've discussed about aligning the environments and ensuring user permissions. In this opportunity I would like to discuss more on the development side of things in terms of how you should structure your project, etc.

When writing custom code for Sharepoint (be it web-parts, custom controls, etc), there is a chance for developers to use third party DLLs. Not only that, you may actually download the whole third party's WSPs. In this article, I will discuss how we should develop our code including how we should manage third party DLLs and solutions. Once again, please also share your experience.

I've been in a project where no one actually knows what version of the code deployed in Production is. Even the third party DLLs/controls, when I tried to get latest version from vendor's website, they actually appear to be a different version than the ones deployed in Prod.

What's even worse is, I've tried "Get Latest" from Visual Source Safe hoping that I downloaded the right code, but it's actually not! The previous developer has managed to modify the code only on his local machine (and disconnected it from VSS) and deploy it straight away to Prod without re-checking the code back in. The machine that this developer was using was wiped out because he was only a temporary contractor. So then we had to use Reflector to open the DLL in Prod and made necessary changes in VSS.

Having all these experience, I think it's important to discuss how we can minimize development and deployment risks.

Managing Risks in Sharepoint 3 – Solutions and Features Deployment

Whenever I do Sharepoint customization project, I will always go down the Solutions and Features Deployment path. I've discussed about this in my other development articles. I know it can be a more complicated process than just doing everything straight from the GUI but it will save us time later on maintaining it. And in fact, throughout my experience, it can minimize the risk of deploying/storing incorrect version of code. There are things that we have to get right though but let me explain more.

We're minimizing risks (and not removing risks, there are always risks) when:

1. Our deployment document is tight

The very first step to minimize development risk is to get our deployment document tight. Make sure that we write down what we're developing and what we're planning to deploy and also where to get the deployment files from. This information includes (and not limited to):
- The custom solutions we're developing
- Shared DLLs/assemblies that we reference within our project
- Third party DLLs/assemblies that we reference within our project
- Third party WSP/features that we may deploy

I normally come up with two documents for every deployment: Deployment Manual and Release Manual.

The Deployment Manual document contains information on HOW TO DEPLOY the code (it will mention the stsadm command to perform, etc). Imagine if you're purchasing Microsoft Word, there is a help manual on how to install ie (ie. double click on the exe, follow the prompts, etc). That's exactly it.

The Release Manual document contains HOW TO GET the code to deploy. This document will be for internal use only. It will mention something like "Get Latest from VSS on the such and such node, open in Visual Studio and click Build" or "Go to http://thirdpartywebsite.com/Downloads and download Version 3.0 of ControlX", etc.

If we can get these documents produced every time we do deployment then everyone will have the knowledge on what is actually deployed in Production and where to get the files from. This way, we have minimized deployment risks.

2. We structure our TFS/VSS correctly 

I've mentioned to you above that there was a developer who disconnected from VSS and start modifying the code directly then deploy that code to Prod without re-adding back to VSS. His reason was he needed to make a small change to current production code and didn't want to create a new branch in VSS because the current code in VSS has already got new functionalities and it will confuse the team later on if he created too many nodes of the same code (it actually confuses everyone afterwards anyway). In VSS we don't have such a good merging system unfortunately, but in TFS we do and using the merging functionality of TFS, it can help us handling the typical scenario above. I normally structure my TFS like this (for every project):

Project Root
—— Development
—— Main
—— Production
———- v1.0
———- v1.1
———- v1.2
etc

- I normally do the development in Development node then when it's ready for Iteration 1 testing, I branch to Main.
- I keep developing more and more functionalities in Development while the code from Main is tested by Testers/Project Managers.
- When the bug report comes, I fix the bugs in Main.
- I then merge from Main to Development so that Development now contains new functionalities plus bug fixes from Iteration 1 report.
- When I'm ready for Iteration 2 testing, I merge from Development back to Main so that now Main contains new functionalities and bug fixes and it's ready for Iteration 2 testing.
- The process repeats over and over again until it's ready for release.
- When it's ready for release to Production, I would branch from Main to Production -> Version node.

My Release Manual will then include information on how to build the code in Production/Version node and my Deployment Manual will then include information on how to deploy the built code. After I do this, I'm pretty comfortable that I've now captured all information about a particular release including what version of code is currently in Prod, etc.

When I need to do another major release, I will create a new branch under Production with a new Version number and I will update my Release Manual and Deployment Manual. You can find this TFS structure in Microsoft's website. I found by structuring my TFS right, I minimize my development and deployment risks and it's pretty clear which node in TFS has the latest source, etc and I know exactly which part of the Production branch is currently in Prod.

Going back to VSS, since it doesn't have any merging capabilities, labelling would be the way to go. With VSS it's a bit tricky to create versions of the code and I don't think it's possible to perform Dev, Main, Prod branch/merge as TFS.

3. Our customization code ALWAYS lives in Visual Studio and Source Control and always strong-name your assemblies

I will ALWAYS deploy Sharepoint customizations using Features and Solutions because it means that all Sharepoint customizations I'm developing live in source control application which then makes it easier to maintain and share. Please read my Development Best Practice articles. Customization code includes:
- My code
- Third party code
- Third party images, CSS, javascripts
- etc that is not Sharepoint OOTB

Strong naming your assemblies is always a good practice even when you're doing development with general .NET application. Sharepoint makes a huge use of assemblies in GAC and you can only deploy your DLLs in GAC if they're strong named (including third parties'). What's interesting is, not all third party assemblies are strong-named. Therefore, ensure that you strong name all assemblies that need to be deployed to your farm including third parties'.

To strong-name third party assemblies:
http://social.msdn.microsoft.com/Forums/en-US/clr/thread/35930958-9775-4e56-bd38-0362d124ffc4

4. Always guard your code from memory-leaks

Whenever you reference SPSite and SPWeb instance ALWAYS guard them with "using" statement from memory leaks. For example:

using(SPSite site = new SPSite(http://url))
{
       using(SPWeb web = site.OpenWeb())
       {

       }
}

There are exceptions though:

If you're referencing SPWeb, SPSite or RootWeb from SPContext.Current, do NOT dispose or you'll get an error. The following code does NOT have memory leaks anyway:

SPWeb web = SPContext.Current.Web; –> GOOD
SPSite site = web.Site; –> GOOD
SPWeb rootWeb = web.Site.RootWeb; –> GOOD

Use SPDisposeCheck tool (http://blogs.msdn.com/sharepoint/archive/2008/11/12/announcing-spdisposecheck-tool-for-sharepoint-developers.aspx) to check for memory leaks within your custom assemblies.

5. Always check that you're NOT deploying ANY of Microsoft's DLL (such as Search DLL, etc)

When you're adding a reference to Microsoft.Sharepoint.dll in Visual Studio, it's going to add reference to Microsoft.Sharepoint.Search.dll.

If you're adding reference to Microsoft.Sharepoint.Publishing.dll, it's going to add reference to Microsoft.Office.Server.Search.dll, Microsoft.Sharepoint.Portal.SingleSignOn.dll and ssocli.dll.

Make sure you REMOVE all of them from your WSP (if they're included by your automated built commands such as STSDEV, WSPBuilder, etc) otherwise your farm will break because these DLLs are overridden by update patches in the future and if you deploy them, Sharepoint will get confused in terms of which version to use.

CONCLUSION

They're so far the things that I will be aware of when doing Sharepoint development and deployment. Please share your thoughts.

Tommy

INTRODUCTION

Hi everyone, I've read several blogs about using virtualised environment (VE) for Sharepoint development which I totally agree. I'm not currently using it because I'm using a laptop and you know what the VE performance is like on laptops. But anyway, having said that, few days ago I was asked to create VE image which can be distributed to developers. I'm working at a client site where I have to use powerful desktops (hence VE is a viable solution).

I've got no problem at all creating the image until I need to distribute it to the developers. If the developers turn on the image at the same time and they set the network settings of VPC/VM/Hyper-V to allow the image to be visible on the network, we will then have a lot of computer name collisions! The developer who turns on the image first will win of course.

So, we have to go through the VE machine renaming process. I've read several blogs such as http://www.bloggix.com/blogs/microsoft/archive/2009/05/18/rename-your-moss-installed-virtual-machine-vpc-vmware.aspx. but I couldn't get it working. In this opportunity I want to share the steps I took (especially the steps that were not described in that blog article) and if you guys have done it differently, please share them as well.

Note: My VE image on this blog article is at the step where I was just finished install MOSS and even not yet activating services, creating sites for SSP and My Site and creating SSP itself.

THE STEPS

- Login to VE image using the account you installed MOSS/Sharepoint in the first place, mine is OLDMACHINENAMESP_Admin. The account I was using as the farm service information was OLDMACHINENAMESP_Farm.

- Go to Central Admin -> Operations -> Alternate Access Mappings and set the web application to Central Admin. Set the URL (mine is http://oldmachinename:6000) to the new machine name (http://newmachinename:6000).

- Run stsadm -o renameserver -oldservername oldmachinename -newservername newmachinename

- Go to My Computer -> Right click, Properties -> Change the computer name to newmachinename

- Restart

- Run stsadm -o updatefarmcredentials -userlogin NEWMACHINENAMEsp_admin -password yourspadminpassword

- Go to SQL Management Studio and open Security -> Logins folder. You will see groups/users with OLDMACHINENAME reference such as OLDMACHINENAMESQLServer2005MSFTEUser$OLDMACHINENAME$MSSQLSERVER. Rename all of them to use NEWMACHINENAME as the domain information (Note: Do NOT modify the name, just modify the domain).

- Remove and re-add NEWMACHINENAMESP_Farm from Central Admin Content DB and Sharepoint_Config database.

- Open Registry Editor (regedit.exe) then go to HKLMSoftwareMicrosoftMicrosoft SQL Server90Machines and modify the OriginalMachineNameKey value to the new machine name.

- Open Central Admin and go to Operations -> Update Farm Administrators. Remove and re-add NEWMACHINENAMESP_Farm and NEWMACHINENAMESP_Admin. When doing this you will see the display name is still using old machine name. That's OK but the account reference is now referencing the new machine name. Just click on SP_Admin or SP_Farm user and you will see that the reference has now been updated to NEWMACHINENAMESP_Admin and NEWMACHINENAMESP_Farm respectively.

- Go to Application Management -> Site Collection Administrators. Modify the Central Admin web application's site collection administrator to NEWMACHINENAMESP_Admin. This setting is used by Sharepoint to create SSP. If you don't update this, your SSP creation will fail.

- Go to Operations -> Services on server and Activate all services (search, etc)

- Create 2 Sharepoint websites for SSP and MySite

- Create SSP –> I used to get a failed message when I didn't do these steps correctly. Therefore, if you get a Successful message after this point then you're good.

Hope this helps,
Tommy