Saturday, June 30, 2007
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
We will live with the orphans and deal with them after the migration to MOSS 2007.
Monday, June 18, 2007
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
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.
SQL Server Service
SSP App Pool
SSP Service Account
Windows SharePoint Services Search
Search Default Content Access Account
Search Specific Content Access Account
User Profile and Properties Content Access Account
Excel Services Unattended Service Account
App 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:
SSP search database