Monday, December 17, 2007

Most of you will already know this, but VS 2008 has been released. Experience all the new functionality by downloading it from here.

WSS 3.0 and MOSS 2007 service pack 1 has also been released. You can view the details here. Just a word of advice, unless you have a critical need that is addressed by this release - wait to hear other people's upgrade experiences before jumping the gun on this one, especially in a production environment.

Sunday, November 18, 2007

Now let’s cover how we subsequently rebranded our intranet and increased employee self service to drive user adoption.

The strategic goals (from a company perspective) of the MOSS branding project were as follows:1. Brand intranet.2. Role/Persona approach versus functional. We developed a persona based approach to content delivery. Identified roles in the company and organized content so that these roles would have most of their daily needs served in one place. (We conducted a company-wide survey in which we asked people to organize information into buckets based on their roles and factored those results into our solution).3. Minimize clicks / navigation to critical information. This is aligned with the above goal. We wanted to allow colleagues to get to information as fast as possible.4. Page based delivery. We wanted to surface information in terms of pages which colleagues could easily read instead of abstract documents in a document library where a guess was usually required to find the needed information.

We identified two distinct project tasks in line with the above goals:1. Develop the company brand.2. Create the content to support the strategic goals. This was an important step because the content had been created in terms of documents in libraries. We had to pull out this information into user-friendly pages to enable employee self service.

The distinct pieces are explained below:

Develop the company brandWe engaged a design company to create the brand for us. Here is what the original provided design looked like:

We modified the design slightly to make the best use of SharePoint features. We then signed off on the design and got to work on implementing it.

User InterfaceThe various elements of the user interface are master pages, page layouts, site definitions, Web Parts, navigation controls and xsl transforms for placement of content.

Master pagesThere are three ways we could have chosen to build the custom master pages.1. From scratch - not recommended as SharePoint 2007 needs a few placeholders to be present in the master page or else the pages will not work.2. From minimal.master - not recommended for a collaboration intranet, serves a .com site much better. The reason is that in a collaborative environment, you want to use OOB features and controls that SharePoint provides and a lot of these are declared in default.master.3. From default.master - recommended as this allows you to use most of the collaborative controls already present on the master page. This master page does have a learning curve though.

We chose #3 and developed the master page for global branding. We took out what we did not need but retained a lot of the collaboration functionality declared in default.master. The master pages were developed using SharePoint Designer along with the style sheets that are discussed below.

These master pages were deployed as features to the target server. A note worthy of mention is that Microsoft recommends that we do not change application.master so we left it as is. That did cause a little confusion but we covered it pretty well in training. Only the site admins and the content authors saw this difference anyway, the majority of users did not.

Page LayoutsWe worked with the design company to come up with page layouts that would enable us to serve content in line with the corporate strategy. This meant modifying the 9 predefined page templates to provide the desired content layouts. This was done for both the SMARTPGS templates as well as the BLANKPGS template.

We used SharePoint designer to modify the page templates. We took off the override for the left navigation placeholder to allow the site left navigation to show up from the master page. We also changed the percentage widths of the table columns to better suit our business requirements. This provided all our pages with consistent branding so as to reduce user confusion.

Site DefinitionsThe business requirement was that when new sites are created, a predefined set of Web Parts should appear on the default page for ease to the content author as well as from a governance perspective. The other requirement was that the brand should be applied to the site upon creation.

We developed 5 new site definitions that would serve 95% of the typical needs. We modified these site definitions and created/modified the WEBTEMP.xxx.xml and the ONET.xml files to place the selected web parts on the page. The recommendation here is to copy from the existing sts site definition and then rename and modify that to create a new site definition. We also wrote a custom provisioning provider that would intercept the site creation request and assign the correct site template and master page to it to meet the business requirement.

NavigationWe needed consistent global navigation across many site collections to ensure consistency and enforce the brand. We also needed current navigation that could be maintained at a site level. After some investigation we decided to develop list based custom navigation providers that would meet the needs of global and current navigation. This was also a very user friendly solution in that it allowed the appropriate users to set up and easily change global and current navigation in a custom list, with no IT involvement. To improve performance, we cached the global navigation tree so it would not need to be assembled for every site.

This is a view of the global navigation shared across all site collections. It includes one level of dropdowns.

Here is a view of the current navigation which is specific to every site:

We created custom site columns, custom content types and then a custom list that used these content types to allow users to easily build hierarchies that the navigation provider could read and deduce the navigation levels. Here is an example of the custom list for the top navigation content. The actual URLs below in the Url Link column have erased, but this should get the point across.

Building custom navigation providers means that we did not have to build special navigation user controls, we made minimal changes to the master page to switch to our navigation provider for navigation content. One tip here is to start debugging your provider early and often. For folks developing custom providers for the first time, it would be prudent to develop them in ASP.NET first to get a good understanding of how they work, only then proceed to build them in SharePoint. We used Visual Studio 2005 to develop and debug the custom navigation providers.

We would like to point out that not only did we reuse SharePoint to hold the data, but we are also using the SharePoint security permissions to secure who is able to get access to and change the data in the list, and ultimately the navigation.

CSSWe used CSS styles to achieve our design goals. Core.css defines most of the standard SharePoint CSS classes. Every site and application page is linked to core.css. We left core.css intact (as is recommended by Microsoft) but 1) changed the direct references to core in default.master to point to a custom style sheet and 2) overrode some of the other indirectly referenced core styles by defining a few styles in the master page itself. We also developed secondary style sheets that would enable us to change the color theme on sub sites easily and used the AlternateCSS setting to attach the secondary style sheets. The effect is shown below.

Web PartsWe purchased a few third party Web Parts that served the business needs really well. These included a stock ticker Web Part, weather Web Part and an image rotator Web Part that gave us quick bang for the buck. We also used XSL transforms to place information in a desirable manner using the Content By Query Web Part.

The final design looked like this:

Content CreationAs discussed earlier, most of the content was previously stored as documents in libraries. From a company strategic perspective, we decided that in order for the more relevant content to be of greatest use to colleagues, it would need to be pulled out from documents and surfaced on pages along with action items that users might consider after reading the information. In our mind, this strategy would go a long way in driving user adoption and employee self service. We assembled a content creation team that encompassed content authors from all departments who would then be responsible for the relevant content for that department.

This strategy did indeed pay off and user adoption increased many fold.

This entire branding project was fast paced and was completed in 6-7 weeks from the inception date. The newly branded site went live on October 1, 2007 with only 4 support calls the entire first week. There have also been no issues reported since that time, so the project team is proud of the work we have done.

Update on Persona based approach: Persona based approach basically means (to us) as understanding the user types (personas) that will be visiting the intranet. Once we divided people into categories (such as general workers, managers, executives) we went ahead and developed persona based sites so that these classes of people could get all or most of their day to day needs served in one place (as opposed to trying to find this information and wasting time). Examples of day to day needs include employee benefits information, travel guides, travel expense forms, career center, information for new colleagues to get started, rewards information, recognition information, performance mangement tools for managers, learning center links, ethics and compliance links. This simplifies the dissemination of information, updates, as well as keeps the single source of information intact.

Here is a snapshot of the Departments and Teams page. This is just a listing of where to find more information, most of our departments were in different site collections.

Friday, November 16, 2007

OverviewApproximately 3 years ago, we successfully completed a project to migrate the corporate intranet to SharePoint 2003. The project was primarily driven by IT, wherein we analyzed and selected a product which would meet the needs of the business; hence the business would thank us for finding a great product and adopt it. We selected the right people to be site admins and delivered training to these individuals with the mandate that they would drive adoption in their respective business units. However this did not turn out to be the case. We noticed that initially the user adoption increased but then started tapering off as users started finding little quirks in the product. Some of the notables were that search did not always get the most relevant results, it was cumbersome to navigate from one site to another or to get a feel for where you are in the site hierarchy, navigation links were not security trimmed leading to frustration etc. to name a few. We only branded the main areas of SharePoint 2003 but not the sites which led to an inconsistent look and feel. Finally, there was no governance committee to oversee the intranet and hence company colleagues were free to do what they liked. This amounted to information being stored in the form of documents in document libraries, which was hard to find without explicit instructions.

Below is an example image of how the SPS 2003 intranet looked earlier this year.

The MOSS 2007 opportunityMOSS 2007 provided an enhanced feature functionality set. We performed an initial assessment against the pain points and determined that the MOSS enhancements/OOB features met IHS strategic goals. We went over the features and placed them into two buckets based on priority, ones that we need now vs. others that could wait. This helped us decide the licensing model for MOSS. We devised the hardware architecture and evaluated the different migration approaches/risks. At the end of this phase, we decided to go with the Content DB migration option. The reasons for this are follows:1. IT initiative to consolidate to a single hosting center with leading practice hosting services and monitoring. Our intranet was hosted on 32 bit architecture and we preferred to move to 64 bit to utilize the performance benefits that it offers. Another motivator was that the cost difference between the two was minimal.2. We had over 100 GB of data, but the majority of data was stored in WSS site collections, not in SPS areas. We only had a few areas and we were willing to lose those, as they did not contain any required information, they were just hooks into the appropriate WSS sites. We also had a few custom site definitions - but we were only interested in upgrading a couple of them.3. We tried a couple of trial runs of the migration using the content database approach - and things migrated over pretty well for the most part.4. Microsoft does not recommend the in-place upgrade because if something went wrong during the migration, it’s difficult to restore.5. We did not want to go with the gradual migration approach as well because there was risk in our mind. This included installing both MOSS and SharePoint 2003 on one production server, performance issues this may have caused, disk space issues we may have run into given that we were running out of disk space on that server.6. We also evaluated four 3rd party tools that we felt could assist us in the migration but turned them down because they did not meet our needs completely, or that significant post migration cleanup would be involved.

Finally, the intranet goals for IHS were:1. Strategy / GovernanceDefine intranet as critical component to corporate communication strategySolidify our intranet strategy, usage and measuresForm an internal governance council and supporting processes2. Content Migration / Foundation UpgradeCoordinate migration with business to minimize user impact/downtimeSupport customizations and integration points3. Branding & Content Re-organizationTake a role/persona approach versus functionalMinimize user clicks / navigation to critical informationImplement a page based deliveryAfter finalizing the migration approach (which was our single biggest X factor), we went back to planning the migration and worked on the documenting the four phases that any SharePoint migration consists of: Planning, Preparation, Migration and Clean Up. A big misconception in people's minds is that the planning and preparation phases are very small and the actual migration and clean up phase is what matters. Nothing could be further from the truth. To the contrary, the planning and preparation phases are critical to the migration and should be allotted ample time. To underscore how important the planning phase is, here are some of the tasks we completed in the planning phase: understanding the big picture and defining future state, understanding the current deployment and usage, assessing SharePoint 2007 features, licensing, planning and validating architecture, getting buy in from all business units and executive sponsorship, choosing a migration option and running test migrations, planning customizations, creating a networking and domain name plan, creating a communication plan, creating a testing plan and training users on moss etc.

IHS Project ApproachHere we will provide a high level overview of the approach we took with the SPS 2003 to MOSS 2007 migration.1. We used standard software lifecycle methodology (Design, Develop/Test, Deploy).2. Solicited executive sponsorship and created a governance team. We also formed a collaborative project team (IT & Business). This gave us a big boost as the corporate communications and key business stakeholders "owned" the intranet migration and therefore took it upon themselves to push for governance and adoption. IT was no longer a driver, but a facilitator.3. Gathered necessary requirements for design.4. Defined scope – business approval. We effectively split the project into 2 phases: the as-is content migration to MOSS and then subsequent creation of the company brand. We separated these goals into 2 different projects to tackle each one individually and ensure nothing fell through the cracks juggling two sets of tasks.5. Used content DB migration. The reasons for this decision are explained above.6. Did not upgrade 2 out of 4 custom site definitions as we felt that MOSS would address these needs OOB. We wrote custom site definition and upgrade files so that the remaining site definitions would upgrade successfully.7. Did not migrate MySites as the user adoption was very low and we discovered through communication that the users would not mind losing their SPS 2003 MySites.8. Did not migrate any 3rd party Web Parts as these had to do with navigation. MOSS 2007 provided this functionality OOB.9. Did 4 trial migrations to ensure that content migrated and the development team was comfortable with the result. This also allowed us to tweak our steps in the migration phases.10. Established Training and Communication plans for end users and delivered worldwide training.11. Created a testing plan and performed testing to ensure that the hardware would be able to serve our users and that there would be no performance concerns after go-live.12. “Froze” SPS 2003 for 3 days as we moved the 100 GB database over and completed the migration, clean up and final testing for MOSS. This means that SPS 2003 was in a read-only state.13. The DNS change was transparent as we just changed the entries to point to the new servers. The users entered the same URL and they were taken to the MOSS 2007 intranet instead. We still maintained the old intranet as a different URL if users wanted to compare or felt they had missed something. Fortunately the number of such requests was less than 5.14. Performed migration in off hours and over the weekend. This limited the downtime as a small minority of users use our intranet over the weekend.15. Re-architecting SharePoint content in terms of pages. As mentioned previously, without active governance our SPS 2003 had become more of a document repository than we were comfortable with. So the governance team took it upon themselves to engage colleagues from various business units who would build informational pages and links to next steps. This is an ongoing operation and will be discussed in part 2 of this series.

Here are the high level upgrade experiences1. The upgrade took 4 hours. We migrated 800 sites and 100 GB of data.2. All the WSS site content migrated with the same structure as SPS 2003.3. Search scopes, keywords, best bets, audiences were recreated as these did not migrate.4. We needed 2 days of post migration cleanup and tasks – links, web parts that were not migrated, scripts, integrations with other applications.5. Communication had to be repeated as some users did not read that the intranet would be read-only.

To learn other migration Do's/Don’t's and if you need further information about the tasks we completed in each migration phase, please see the slides (from my September blog post) from a recent presentation at the Rocky Mountain SharePoint user group where we spoke about our migration experience.After the migration, here is what our SharePoint intranet looked like. We added the Under Construction image to indicate that this was a temporary look before the final branding.

In part 2 of this series, I will talk about how we branded SharePoint 2007 for our intranet.

Thursday, November 8, 2007

Sometimes you will have a requirement to rebrand your site with a new domain name for various business reasons. We had a business case a little over a month ago wherein we had to change the brand for our intranet. The requirement was that users visiting the old site would get redirected to the new site automatically. History: We had migrated our SharePoint 2003 intranet to MOSS 2007 and we now wanted to give it a new brand to drive excitement and adoption.

Here is a slick way that I devised to achieve this switch easily. This worked like a charm so if you have a similar business case, test this to decide if this will meet your needs. The URLs and Website names are made up, but they serve to demonstrate how this is done.

We had 2 Web applications for the intranet (one for the main portal and one for MySites). The DNS names were oldintranet.ihs.com and mysite.oldintranet.ihs.com, as an example.

The new DNS names we decided to go with were newintranet.ihs.com and mysite.newintranet.ihs.com.

Here are the steps:

1) On the target server, assign 2 new IP addresses. This is because you can only have one SSL Website enabled on one IP. Create 2 new Web applications (a collaboration portal for newintranet.ihs.com and a MySite for mysite.newintranet.ihs.com) on these 2 new IPs.

2) Procure and attach the appropriate certificates to these Web applications (if using SSL). Create the relevant site collections for these Web applications. Make sure that the new web applications work correctly when you browse to them.

3) Make sure to save the certificates as text files on the C: or D: drive for all the 4 Web applications involved.

--- So now we have a total of 4 IIS Websites. Lets assume these are called MOSS_IHS_Intranet_Old and MOSS_IHS_Intranet_Old_Mysite and MOSS_IHS_Intranet_New and MOSS_IHS_Intranet_New_Mysite. ---

--- Here is where you will have a few minutes of downtime, so do this during a maintenance window ---

4) Go to central administration and change alternate access mappings for newintranet.ihs.com to newintranet2.ihs.com. Similarly change alternate access mappings for mysite.newintranet.ihs.com to mysite.newintranet2.ihs.com. (We change these to arbitrary names so that some other Web application can claim the names that we are changing).

5) Now change alternate access mappings for oldintranet.ihs.com to newintranet.ihs.com and mysite.oldintranet.ihs.com to mysite.newintranet.ihs.com. (Now we change the old headers to the new ones so that the new headers serve content for the old Web application - which is where the content lives anyway. MOSS will do the heavy lifting of changing all the links served on pages to the new URLs we just applied. An exception to this is hard coded links in the Content Query and/or the Links Web Parts).

6) Similarly, now change alternate access mappings for newintranet2.ihs.com to oldintranet.ihs.com and mysite.newintranet2.ihs.com to mysite.oldintranet.ihs.com. (Now we claim those old headers for the new sites so that the old url effectively points to the new Web applications - which have little to no content. We will use these old host headers to merely redirect users to the new URLs).

-- So far we have only done half the work --

7) Go to IIS, right click on the old Website MOSS_IHS_Intranet_Old, click on the Web Site tab and click on Advanced. Here change the host header value from oldintranet.ihs.com to newintranet.ihs.com. This is to match in IIS what we did with alternate access mappings so everything is in sync. Do this for all 4 IIS Websites in question.

8) Change the certificates in IIS. As the host headers were mismatched, so are the certificates. Right click on Website, click Properties and browse to the Directory Security tab. Click on Server Certificate --> click next --> Remove the current certificate. Then attach the certificate that matches the newly changed host header from your hard drive (these were saved in step 3). Do this for all 4 IIS Websites.

9) Swap IPs between the corresponding Web applications. In IIS, right click on Website --> Properties --> Web Site tab --> Advanced --> change IP for both the "Multiple identities for this Web site" as well as "Multiple SSL identities for this Web site". For example, swap IPs between MOSS_IHS_Intranet_Old and MOSS_IHS_Intranet_New as well as between the MOSS_IHS_Intranet_Old_Mysite and MOSS_IHS_Intranet_New_Mysite. This is done to preserve the original IP mappings that we had after step 2. This also helps in keeping the same IP address for the old site and the new site. The new DNS names could then be pre-advertised so that after you are done with this step the old content is being surfaced using the new host header. No funny DNS entry changes required at the last minute.

Now you are done.10) Now finally add a redirection to the old host headers (newly created Websites) so that they exist merely to redirect all requests to the new host headers (attached to the old Websites where the old content will be surfaced). Go to IIS --> right click on newly created Websites --> Properties --> Web Site tab --> "The content for this resource should come from: --> Select "A redirection to a URL" and specify the URL to be the corresponding new host header. (Do this for both the new Websites.)

You are done. This method may sound complicated, but its not - if you understand what is going on. What we have effectively done is switched which host headers are responding to which content. So now when you browse to the old url, you are automatically redirected to the new url which is serving the old content - the links are automatically changed.

This also helps in house keeping. Once the new url has been sufficiently advertised, you are free to delete the Web applications that are serving the old url, because they point to the new content - which is meaningless for your purpose anyway.

Realize that there are other methods of achieving this goal, but this works pretty well and has the advantages listed above.

So I haven't been able to blog for the past month and a half coz I have been busy travelling to a lot of places. I visited Bombay, Dubai and London for vacation and it was pretty awesome to say the least. I'll post some interesting pictures of the trip on here soon.

Wednesday, September 19, 2007

As promised, here are the powerpoint files from last night's presentations. Thank you to all those that attended. A special thanks to all those who stayed till the end, even though we were way over time. Hope you all learned something. Please feel free to email me if you have any questions. I will be posting shortly about the migration and branding experiences here as well.

Monday, September 17, 2007

So tomorrow I am presenting at the Rocky Mountain SharePoint user group with my team. We will we talking about our experiences migrating from SharePoint 2003 to MOSS 2007, lessons learned, Do's and Dont's etc.

Right after that presentation, I will also present our learnings and experiences with branding MOSS 2007. This will include using custom navigation providers with list based navigation, building the master pages, style sheets and application of style sheets, changing web part pages to include left navigation, creating custom site templates which display our chosen web parts on the home page, customizing styles in the Content By Query Web Part using XSLT etc. It should be pretty interesting.

Matt Passannante (RM user group president) also asked me to run the user group tomorrow since he will be unable to make it. Talk about screen time!!

Monday, September 10, 2007

I recently developed a crafty list based custom navigation provider in MOSS that shows custom nav for the global navigation and the current site navigation. We are also working on SharePoint governance in our company and are encouraging users to create meaningful landing pages to surface links to documents instead of just creating sites and going straight to document libraries.

The requirement is that the current navigation also be available on Web Part pages, since it does not appear on there by default because the default Web Part page is meant to really hold more content and not so much navigation. So I had to create a custom page from spcf.aspx file and rename it Customspcf.aspx. I added my custom link in create.aspx to call Customspcf.aspx for creating new Web Part pages. Then I browsed to the \12\TEMPLATE\1033\STS\DOCTEMP\SMARTPGS folder and tried to add my new custom page there. I reset IIS and my new Web Part custom page did not show up in the Customspcf.aspx page (it only showed the default 8 page layouts).

I played around with it a little bit and here is my conclusion. Unless I understand this wrong, MOSS does not allow you to add custom Web Part page layouts to the 8 already pre-configured layouts. In order to add one, you must replace one of the existing layouts with yours. Bummer!!

So I did exactly this to the spstd1.aspx layout. I also went ahead and removed this line <asp:content runat="server" contentplaceholderid="PlaceHolderLeftNavBar"></asp:content>, which basically overrides the left nav placeholder content from the master page with nothing. The left navigation then showed up on the custom Web Part page!!!!

I also went ahead and removed the footer Web Part zone from the spstd1.aspx file as well as changed the width of the left zone to be 70% of the available area. This gives us more space to insert Content Editor Web Part and make the Web Part pages behave more like traditional pages with navigation on the left, content in the center and some links on the right.

TIP: Try not to change create.aspx using SharePoint Designer. You will most likely get an error 'The file '/_layouts/_layouts/application.master' does not exist. at System.Web.UI.Util.CheckVirtualFileExists(VirtualPath virtualPath) .....'

Monday, August 27, 2007

Microsoft has done quite a bit to ease pain of navigation in MOSS, but there are plenty of scenarios when you would want to have a custom navigation scheme. I am currently building a custom navigation provider for MOSS 2007, which does not need to depend on the site heirarchy and can go many levels deep if need be. I was having trouble debugging this navigation provider (which was created in Visual Studio 2005 as a class in a class library project).

I created and compiled the dll, strong named it and deployed it to the GAC using gacutil. I also added the entry in the providers section. After some cajoling, the custom navigation started showing up in MOSS (not exactly how I wanted it yet, but doing one thing at a time helps ). Now, of course I wanted to debug it :). This is where I came across interesting scenarios. I removed the dll from the GAC and changed the VS output to go straight to the bin directory of the web application. I then got the expected error 'The assembly does not allow partially trusted callers'. Then I added the AllowPartiallyTrustedCallers attribute to the assembly - and guess what (it still didnt work). I then added a safe controls entry and an assembly entry for my assembly and raised the trust level of the web.config to WSS_Medium and it STILL complained about the same error. At this time I raised the trust level to full and that is when things started working.

I think I know why I had to do this but Ill run it by some MCS folks and see if I am right and then update this. Ill also write up an article explaining the design and architecture of the custom navigation provider soon.

Wednesday, August 22, 2007

As you all might or might not know, WSS 3.0 and MOSS 2007 support folders in lists. This is honestly a really cool feature/enhancement to the list functionality. This opens the door to a lot more possibilities.

However, you need to be a little careful with traversing lists that you create folder heirarchies in. Traversing a list is not as obvious as you think. I was a little surprised that the solution was not intuitive.

Here are some of the caveats that I discovered:1. A call to list.Items will not bring forth your folders. Instead, it will bring forth ALL the regular items, regardless of the folder heirarchy they live in. So it doesnt matter if an item is at the root level or 4 levels deep - it will show up in the call to list.Items.

2. We have another property available for the folders :). However, a call to list.Folders will bring forth all the folders regardless of their heirarchy in the list.

Keith Ritchie has a solution that works and he has done good homework around this problem. Be sure to have a look at his post here.

Wednesday, August 1, 2007

I just added a MOSS utility (to my growing list of MOSS utilities) that would allow me to enable treeviews on all sites programmatically, rather than going into each site doing it manually. This is significant time savings when you are doing a migration - because there are potentially hundreds of sites that already exist and treeview is not enabled on them.

Here is the code. This assumes that you run a stsadm -o enumsites on the server so that you can get the list of the site collections on your server. This also assumes that you are reading that list from a config file (because you might want to run this for a subset of your site collections).

I recently wrote, tested and deployed a .NET 2.0 Windows service to import files into MOSS 2007 sites and document libraries. This service watches a file share (using the FileSystemWatcher class) on another server and moves the file into a MOSS 2007 document library. Here are the salient features:

1. Watches the file share and all folders under that share. Picks up the files as they are created/changed on this share and imports them into MOSS 2007. Deletes the files from the file system after the import. The users are responsible for ensuring that the

2. Accounts for the long copy operations, when the file may not have finished copying when the service goes to pick it up. The way to do that is to open the file in FileShare.None mode and catch the appropriate exception. Wait for a given period of time (few seconds) and retry. Do this the appropriate number of times based on the requirements.

3. Does a clean sweep of the system everytime the service starts to account for the files that it might have missed since the last time it was stopped.

4. Logs the files published/errors to the event log. This helps to track the health of the service - understand what is going right/wrong.

A few things to keep in mind:

1. In the installer class, do not hardcode the password of the account under which the service will run. Do not even read the credentials from a config file. I asked our production environment admins to run the service under a moss service account with enough privileges.

2. Do not do an infinite loop on the number of retries when you cannot get exclusive access to the file. If somebody opens the file and goes home for the day, your service is going to be spinning its wheels trying to get access to that file all night.

3. Review the business case for this requirement. If all that is required is to index these files, you could use MOSS Search to index file shares pretty easily. Also review the business users understand the capabilities of your service, so they dont tax it by creating bogus directories and putting thousands of files in them.

All in all, this service really helps the business because they can automatically import thousands of files into MOSS just by copying them into a file share. I cannot publish the code because the company "owns" that, but hit me up if you need help/advice on how to do this and Ill be glad to guide you.

Tuesday, July 17, 2007

I just got bit by this recenty. ALWAYS run prescan.exe on your SharePoint 2003 environment before you migrate to MOSS 2007. Prescan prepares the database for upgrade. In particular, it parses and saves list definitions with the associated lists, as well as reports any errors that will cause the upgrade to fail. I have already done 2 SharePoint 2003 to MOSS 2007 migrations in a test environment and things moved over pretty well (I did this to document the post migration steps required for our environment - VERY GOOD PRACTICE). Finally when we were migrating to stage -- upon attaching the database using stsadm I got the following error.

"The [Databasename] on [servername] contains user defined schema. Databases must be empty before they must be used. Delete all tables, stored procedures and other objects or use a different database".

After going over what we did differently this time, we realized that we had forgotten to run prescan that day before backing up and moving the database. So we did exactly that and the migration to stage went as expected.

Thursday, July 12, 2007

I have been going back and forth a few times on enabling SSL on MOSS 2007 Web applications and here is the way that I have found to work best.

1. Go to central admin --> Create or extend a new web application --> Create a new web application.2. Fill in the Web app, DB and App pool names as usual. Select yes to enable SSL on the web application. If you are using host headers for this web app, then enter those too. (Important: Make sure to set the port to 443, not 80).3. After the web application has been created, reset IIS and then open up IIS mmc. Scroll to the IIS website that MOSS just created for you and select the right SSL certificate from the available certificates (Ask your network folks to generate an internal or external SSL cert for you depending on whether this is a test or prod server). Important: Go to the Home Directory tab and click Advanced. Make sure you set the host header and the right IP for port 80. For SSL entries, select port 443 and the IP. (If you have multiple IP's on the server, I usually pick one here for these entries). Click on the edit button for SSL entries and check the 'Require SSL' box. Also check 'Require 128 bit encryption' to make this more secure.4. Now go ahead and create your first site collection for this web app. MOSS will automatically create a new site collection for you and present you with a "https://.." link upon completion. You should now have a SSL ready web app.5. By default, if you want multiple web apps using SSL on the same server - this does not work in IIS 6. If you want multiple MOSS 2007 Web apps to be SSL enabled, there are two ways of going about this. One way is to get as many IPs as you want SSL web apps for that web server and assign one IP per host header settings for port 80 and 443 under IIS Website properties --> Home Directory --> Advanced. The other option is to modify the IIS metabase to allow multiple SSL web apps on the same IP. Be careful with the second option and make sure you know what you are doing.

Sunday, July 8, 2007

I have run into problems sometimes when my development VPC is low on hard drive space. By default, you get 16 GB of hard disk space on the VPC virtual disk. Recently I created a new VPC - installed MOSS 2007, SQL 2005, Office 2007, SharePoint designer and VSTS - and figured I would use this VPC for development around MOSS. Turns out that a few days after the install, a balloon popped up stating that the VPC was running out of space. I did not have many programs that I could get rid of, so I decided to confront the problem instead of delaying it.

I navigated to the Virtual PC console and clicked on settings for the currently running VPC. I clicked on the Virtual Disk Wizard and created a new disk with the default settings to be used as the Hard Disk 2 for this VPC - to get me more space. I shut off the VPC and assigned the Hard Disk 2 settings to use this new disk file. After restarting the VPC, I still did not see my new space on the system drive. So I navigated to Computer Management under Administrative Tools and clicked on Storage --> Disk management. That started a wizard where it asked me to initialize my new disk (if it does not automatically start the wizard, you can right click on the new disk and start it manually). I initialized my new disk and then right clicked on the disk again to format it. I chose the New Volume wizard to basically partition the drive. I chose the simple volume type on the next screen. On the next screen I selected the disk and set the disk size (used the defaults of 16GB) and clicked next. On the next screen, I assigned E: as the drive letter. The next screen presented me choices of formatting the volume or not. I chose to format the drive with NTFS as the file system and named the volume label as data. The next screen just showed me a summary of my choices and I said ok. A few minutes later it was done formatting the drive and I had an extra 16 GB of space :).

Tuesday, July 3, 2007

I was trying to reset iis using the iisreset command and it kept coming back with "Class not registered" error. Turns out that the program IISRSTAS.exe got unregistered. To register it again, run the following command from the console.

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.

Hello everyone. I am a SharePoint and .NET architect/developer based in Denver, Colorado. I architect and develop Web and windows applications in the .NET framework, using established best practices. I also work with other Microsoft products such as SharePoint 2007, SharePoint 2003, Content Management Server 2002, SQL Server among others.

Starting the second half of 2006, I have been doing a lot of SharePoint 2007 work. We migrated our intranet from SharePoint 2003 to MOSS 2007 and then led a second project to brand the migrated portal. I have also completed a CMS 2002 to MOSS 2007 migration to MOSS. Currently I am architecting, designing and developing a large extranet powered by MOSS 2007.