Saturday, June 30, 2007

Some of you might have experienced a problem with windows update in Vista. I installed Vista a couple of months ago and had the same problem. Whenever I would try to update my computer, it errored out with the message "Windows could not search for new updates. Error(s) 80244019. I tinkered around it for a few days before I found the reason and the fix. I had supposedly taken the laptop to work and plugged it into a domain, Vista adds a registry key to look for the WSUS server (when you add it to a domain) - hence my update would not work.

If you have the same problem, here is the resolution. Go to run --> regedit --> HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows. There should be a subkey under this called WindowsUpdate. Delete that WindowsUpdate and the AU key beneath that. Restart your computer and updates should work.

Friday, June 29, 2007

After going back and forth about how we are going to migrate our SharePoint 2003 intranet to MOSS 2007, we decided on using the content database migration approach. The reasons we went with this approach were:

1) We are moving to a different hosting center because our relationship with the current one is going south. We are also moving to the 64 bit architecture as this will help performance.2) We have over 100 GB of data, but the majority of data is stored in WSS site collections, not in SPS areas. We only have a few areas and we are willing to lose those, as they do not come over as part of the migration. We also have a few custom site definitions - but we are only interested in upgrading a couple of them. For the ones we want to upgrade, I have written custom site definitions as well as the upgrade definitions that will tell MOSS what to do with that template when it encounters it.3) We have tried a couple of trial runs of the migration - and things migrated over pretty well for the most part. For what came over and what did not, look for a blog in the near future.4) Microsoft does not recommend the inplace upgrade because if something went wrong during the migration - you are pretty much hosed.5) We did not want to go with the gradual migration approach as well because there was signigicant risk in our mind. Some of the risks include installing both MOSS and SharePoint 2003 on one production server, performance issues this may cause, we were running out of disk space on that server, we wanted to move to a different data center etc.

Those were the reasons. I attended TechEd 2007 and sat through Shane Young and Joel Oleson's migration session. They actually recommend using gradual upgrade option for the most scenarios - unless your database was too large or you wanted to move out of the data center. As you can see above, our case warranted that we go with the content database approach. You should pick one of these approaches, but carefully outline the reasons you are going with either one. This will help you in the long run and ensure a smoother migration.

Tuesday, June 19, 2007

After reading Joel Olesen's blog and the Microsoft kb on how to delete orphans in Sharepoint 2003 a supported way, I was excited to try it out. I requested the hotfix from Microsoft support and tried to install it in my test SPS 2003 environment - which is not a true representation of production but helps out in some ways regardless. After unzipping the neccessary files, I was left with a STS.msp file. When I tried to run that, I got a screen which said that gave me 2 options - Uninstall WSS 2.0 or repair and reinstall it. This would not fly in production - I did a quick test to find out if I would in fact get the same screen and I did. So I exchanged a few emails with Microsoft support and was told that this was an anamoly in my environments and this works in other environments. So basically I abandoned the approach of trying to delete our orphans and potentially bring down our SPS 2003 environment in the process of doing so.

We will live with the orphans and deal with them after the migration to MOSS 2007.

Monday, June 18, 2007

I have been involved with installing MOSS 2007 (with the right service accounts) with our Sharepoint administrator in our test environment. One problem we uncovered when creating the SSP application is that the SSP timer service account would take over the app pool credentials and not allow us to login. This is explained below.

When we created the Web application where the SSP will be hosted, we created a new app pool and added the service account we created (svcMOSSSSPAP) as the app pool identity account in the 'Create web application' page in central admin. Things were great thus far. However, when we went in to create a SSP under that Web application, we would run into a problem where the SSP timer service account that we entered in the SSP creation form (svcMOSSSSP) would end up taking over the app pool identity for the Web application. This would block all access to the SSP. Also, it would not allow us to change the identity in the app pool in IIS (it would reset to the same account everytime we tried to change it). We finally figured out what it was doing and had to create a new app pool in IIS that would use svcMOSSSSPAP as its identity and configured the SSP web application to use that new app pool. We were then able to access the SSP.

Saturday, June 16, 2007

Here is the scenario. We were greatly excited about the new mysites functionality in MOSS 2007. Since a lot of our internal users were not using MySites at all, the business decided that it would be ok to trash the Sharepoint 2003 mysites and users could build their mysites from scratch in MOSS 2007. The other reason this desicion was taken was from a governance and user adoption perspective - the business could tout this as a great new platform and get the users to use MOSS 2007 heavily as their collaboration area.

Needless to say, this made things easy. All of our content was in one big (100 GB) database in Sharepoint 2003, so all mysites came over as site collections using the personal managed path - which the migration automatically created for us. I could go ahead and delete these site collections and start afresh. Hence, I decided to create a new Web application that would separate the content from the big database into a new manageable DB as well as allow for more control and security. After creating a new web application, I created a site collection that used the MySite template (under the enterprise tab). I changed the settings within the SSP administration (user profiles and my sites --> my site settings) to use the new website. All I had to change was personal site services t0 https://mysiteswebapp/ and the Personal site location to 'personal'.

Then I went into my primary content web application and clicked on the mySite link. Lo and behold, I was directed to mysiteswebapp and a message appeared stating that it was creating the mysite for this user. However, I did run into an error which stated that the managed path 'personal' had not been created for this Web application. So I popped into Central admin and added a managed path called 'personal' for the mysite web app. I tried to create mysite again and this time it worked. Great success.

Friday, June 15, 2007

If any of you have tried to install MOSS 2007 with only the service accounts listed in Bill English's book on the service accounts page, you will see the service accounts below.Setup UserSQL Server ServiceServer FarmSSP App PoolSSP Service AccountWindows SharePoint Services SearchSearch Default Content Access AccountSearch Specific Content Access AccountUser Profile and Properties Content Access AccountExcel Services Unattended Service AccountApp Pool Identity

In fact, you will need another account to even complete the initial required tasks. That is the Office Server search account. It needs access to the following databases:

So we have been gearing up to migrate our Sharepoint 2003 instance to MOSS 2007 at our company. I will start posting my experiences here very soon so other people can take advantage of our successes and blunders.