Wednesday, February 23, 2011

Simple ToDo List to Migrate MOSS to SP 2010

For starts its no simple process to migrate from MOSS 2007 to SharePoint 2010. That's because SharePoint is a robust application platform full of site collections, web apps, etc. with plenty of custom features, complications and potential incompatibilities with 3rd party products and user-driven customizations that are abnormal which may not migrate robustly. Nevertheless in order to remember the migration process I'm outlining here some of the key todos.

1. Make sure the existing MOSS 2007 farm is upgraded to the latest service packs and all system issues are resolved. Doing a migration to SharePoint 2010 won't make any issue magically go away. In fact it could just complicate matters.

2. Make the content databases in MOSS 2007 read-only. To set a database to read-only in SQL Server 2008 you open SQL Server Management Studio and use Object Explorer to connect to an instance of the Database Engine, expand the server, and then expand Databases. Select the database that you want to configure to be read-only, right-click the database, and then click Properties. In the Database Properties dialog box, in the Select a page section, click Options. In the right pane, under Other options, in the State section, next to Database Read-Only, click the arrow, and then select True.

3. Copy the .MDF and .LDF files for this database over to the new SQL cluster for the SharePoint 2010 farm in order to implement the content database for SharePoint 2010. In Windows Explorer, browse to the location of the .mdf and .ldf files for the content databases. Select the .mdf and .ldf files for the database you want to move and either copy or move them to the destination directory. In SQL Server Management Studio, open the source instance of SQL Server. Right-click the Databases node, point to Tasks, and then click Attach. In the Attach Database dialog box, browse to the location to which you transferred the .mdf and .ldf files, select the .mdf file for the database you want to attach, and then click OK.

4. Once the database has been restored then run the following command to configure the SharePoint farm.

stsadm -o addcontentdb -url -databasename -preserveolduserexperience true

5. Be sure to do a IISRESET because otherwise it'll look like garbage until the web server resets.

Friday, February 11, 2011

Not thinking about SharePoint just before a Tech Interview

Recently I had my last tech interview w/o directing the screener to my tech Blogs. In a nutshell the interview didn't go as well as it could've. The reason IMO was because I wasn't thinking about SharePoint just prior to the tech interview. In the future that's going to change. 1. I'll do some thinking/focusing on the specifics regarding the new opportunity. 2. I'll be sure to guide the screener to my Blogs.

I had been up since 5am and working all day in Visual Studio, solving IIS communication issues, looking at some class libraries that were having a problem integrating from SharePoint, helping some developers learn about the 4 key FeatureReceiver events & the reasons why you use try-catch in Activating/Deactivating and why you don't override the Installing/Uninstalling events, and solving some JQuery issues. So finally 5pm came and it was time for the phone interview.

The screener at the end said he was concerned that I didn't know much about Sharepoint. I asked why. He said because I didn't even know what the 6 pillars of SharePoint were. And he said that I didn't even know what the SharePoint web services are. He said it looked like I was just working on the types of projects that they don't do much of. I'm certainly not going to give out his name because I'm about the criticize him. IMO he obviously doesn't know how to do effective technical screens. The primary purpose of a technical screen is to validate the person's resume. Are they telling the truth? What types of skills do they have? And if you're hiring them for a position that's "perm" its especially important to find out what their aptitude is like and what things they want to do in the future.

BTW I did know what the 6 pillars of SharePoint were and what the SharePoint web services were. It was just a long day and I wasn't at my sharpest for the interview. And he never had specifically ask what the 6 pillars were.

In SP2007 the 6 pillars were: Collaboration, Portal, Enterprise Search, ECM, Business Process/Forms, Business Intelligence

In SP2010 the 6 pillars are: Communities, Sites, Search, Content Management, Composites, Insights

If I had spent the last 6 months being a SharePoint 2010 salesman then they'd probably be at the tip of my tongue. As luck would have it I've been focused on migrating some pretty complex/difficult applications from SP2007 to SP2010 so I haven't been thinking much about all the buzzwords. However I certainly have been deep in solving search/CM issues, helping site owners figure out wikis/blogs/tags/ratings/MySites/feeds, working with the Ribbon, javascript, integration, taxonomies, workflows, content types, records management, InfoPath, Excel Services, and Performance Point.

BTW see http://www.codebanking.com/articles/sharepoint/sharepoint-six-pillars.asp for a glance at the details.

The SharePoint web services are listed at http://msdn.microsoft.com/en-us/library/ee705814.aspx online.

For example, you can use the GetListCollection method in the http:///_vti_bin/Lists.asmx service to get a list of Lists\List XML nodes in an XML document whose ID/Title properties can be used to help me drill into a specific List object.

However I tend to prefer the more secure, compiled/fast alternative of accessing the Lists property of a SPWeb object I opened up directly with SPContext.Current (or indirectly with its site collection's SPSite object). I've learned with SharePoint that its vital to know how to do effective up-front analysis. That's because many tasks can be self-service, easily done by a site owner, or souped up together by an designer/analyst in SharePoint Designer. The harder stuff needs to be thrown into some sort of application. By default I'm opinionated on this. I prefer building robust ASP.Net user controls to throw into the controltemplates folder underneath the 14 hive (or 12 hive in SP2007 or SP2003). Then I wrap these using what I call the User Control Container Web Part (UCCWP). It has 2 custom properties called Control Path and Control Parameters. The Control Parameters property is a XML string which if set to "help" displays a 3-column grid in the content area listing all the parameters' names, example values, and HTML descriptions. The code for this is specified in the ascx.cs partial class method that implements the base class's HelpHtml method. Of course I've learned that I have to roll with the punches and check my ego at the door on any given engagement I'm working.

I also suppose it didn't help when I told him too much about my experience in customizing Microsoft's Application Lifecycle Management tools/components to integrate with SharePoint and other presentation layers such as traditional ASP.Net, WinForms, WCF, WPF, etc. because too many SharePoint developers think of TFS as being just Version Control like many people view SharePoint as being just a shared file system directory on the network.