I’ve been hesitant to install SharePoint 2010 on my computers, virtualized or otherwise, due to what I think to be steep hardware requirements to run SharePoint 2010. My impression was I needed a beast to run SharePoint 2010. I’ve seen demos where the hardware is a LOT better than what I have and demo choked—super slow response, take forever to reset IIS, etc. So I kept procrastinating to install SharePoint 2010. I’m still shopping around for a super laptop  but the one that I’m eyeing, the HP Envy 14 won’t be out for another couple of weeks. My best hardware is my “production computer” and it has Intel Core i7 with 6GB of RAM but I really don’t want to put a development SharePoint there. But I need to install SharePoint 2010 now! So, I said, what the hell– I might as well put the MacBook Pro 13 to the test! My MacBook is configured for dual boot and runs Windows 7 Ultimate on the “Bootcamp” side.

My MacBook Pro 13 Windows (Ultimate) Experience Index looks like the following:

 

Not too shabby. Lowest score is the graphics (NVidia 930M) but shouldn’t be an issue with regards to SharePoint and development work in general. See that Memory and Primary hard disk scoring 5.9? That worried me. The hard drive speed is only 5400 RPM and that could be a bottleneck for database read/writes. I went ahead and installed SharePoint 2010 on the MacBook Pro/Windows 7 anyway.

Instead of rewriting the steps needed to install SharePoint 2010 on Windows 7 for a development rig, I will point you to existing resources out there. Too many write-ups regarding this topic already. So here they are, the ones that I’ve tried and tested:

• If you are going to read anything about installing SharePoint 2010 on Windows 7, this is the resource you want – http://msdn.microsoft.com/en-us/library/ee554869(office.14).aspx
• Execute EVERY step outlined in that walkthrough. Don’t even try to shortcut or think that you can do it without reading any documentation. You may get past the installation but you will pull hair out when it’s time to configure your farm. So just do it, every step in that walkthrough! I will show some of the errors I encountered when I tried to “fast-track” the SharePoint installation.
• Here’s another good one – http://sharepoint.microsoft.com/blogs/fromthefield/Lists/Posts/Post.aspx?ID=112. This one talks about how to configure the scalable farm (not the Stand-Alone setup that uses SQL Express) for development purposes while using local accounts (instead of domain accounts). SharePoint 2010 needs domain accounts to configure. If you are building a “SharePoint workstation”, it’s very common to use local accounts instead of domain accounts (maybe because getting in touch with the AD admins is not easy—just create local accounts yourself). See, my MacBook Pro is not joined to a domain. I have to use non-domain accounts. I wouldn’t have been able to configure my “SharePoint farm” to use a true SQL Server 2008 if not for this walkthrough. Remember, if you do a stand-alone install, the Web apps use the SQL Express for the databases—not really  my ideal configuration!!

Here’s the first error message I encountered:

I was so excited to install SharePoint 2010 after I got my MAPS subscription that I just double-clicked the setup.exe. The above message is what I got! You have to edit the \Files\Setup\config,xml of the SharePoint 2010 install directory and add the following:

<Setting Id="AllowWindowsClientInstall" Value="True"/>

This was mentioned in Step 2: Install the Prerequisites for SharePoint 2010 of the MSDN walkthrough. Fast-forward to the end of the SharePoint 2010 installation/configuration. In Central Admin, you should see this:

Again, don’t skip any steps—follow each and every one!

In follow-up blog-posts, I’ll show the other errors I received while attempting to install/configure the SharePoint farm and how to address them.

Update 6/11/2010:  Here’s the screenshot of the Windows Task Manager of the Macbook Pro when running SharePoint 2010, SQL Server 2008, IIS Management Console, Internet Explorer, and Visual Studio 2010 (debugging/attaching to processes).

There is big SharePoint team in one of my customers and it’s a good blend of developers, engineers, analysts, and managers. When this team started in 2007, only a handful (2 people really) was knowledgeable in the ways of SharePoint. But because the user-base for this organization is so big, technical resources of other backgrounds started getting recruited to become part of the SharePoint team. Traditional network engineers became SharePoint farm admins. ASP.NET developers became SharePoint developers (that’s how I got into SharePoint). Other Web developers (Coldfusion) became SharePoint developers too.

There are still some Coldfusion developers in this organization but these Coldfusion apps are being phased out and eventually  will be converted to ASP.NET and/or SharePoint. These Coldfusion developers do not have a background on ASP.NET programming model, which is really different, closer to VB6 model if you look at it that it is closer to “classic ASP” model. “Classic ASP”, Coldfusion, and PHP are in the same category in my book—they are server-side scripting. ASP.NET and  SharePoint on the other hand are more object-oriented.

One of the Coldfusion developers asked me which topics on ASP.NET and SharePoint should they learn and in what order. They are excited to develop SharePoint stuff such as Web parts and workflows but need some guidance on where to start.

Here’s the list of high-level skills/topics I pointed out one should in order to develop SharePoint solutions:

• ASP.NET model
  • ASP.NET User Controls
  • Intrinsic Objects (HttpContext, Application, Request, Response, Server, etc.)
  • ASP.NET Page life-cycle
  • C#
  • ASP.NET Web App configuration files
  • .NET Namespaces
• Object-Oriented/Component Programming
  • Properties and Methods
  • Events
  • Delegates
  • Inheritance
  • Implementation (interfaces and abstracts)
• SharePoint Features Development
  • Visual Studio SharePoint Project Extensions/Templates
  • SharePoint Object Model
  • Deploying Features using STSADM

I was viewing my blog today and noticed the tag cloud on my sidebar. The most prominent tags are “SharePoint”, “Developers”, and “Administrators”. SharePoint. Developers. Administrators.

From time to time, I will meet SharePoint professionals in networking events or when interviewing job applicants at a customer site and I will ask what their SharePoint experience is like. “Oh I am a SharePoint Developer“. Then I find out that the extent of their development experience revolves around master-page and page-layout design, style/CSS customizations, and graphical/logo design. Basically, branding tasks. And then there is the “SharePoint Administrator“. “Oh, I am the site collection administrator and manage user-permissions, site-collection features, and sometimes recycle items for end-users from the Recycling Bin.”

I think people are calling themselves SharePoint Developer more than they should. In my opinion, a SharePoint developer is someone who can develop Web parts, workflows, user-controls, Web controls, ASPX pages, client-side scripting, and complete SharePoint solutions. In addition, they also understand deployment options such as creating solution packages. If your experience around SharePoint is limited to CSS, branding, and design stuff, you’re a designer, buddy; not a developer, but a designer.

Now, let’s talk about the “SharePoint Administrator”. Yes, to a point, the site-collection administrator is an administrator. But to me, and again, this is just my opinion, farm admins are the real SharePoint administrators. To call yourself a SharePoint administrator, especially on job interviews, you better know your SharePoint deployment scenarios, Central Admin, SharePoint disaster/recovery procedures, IIS, SQL Server, Windows Server OS, and the beloved “stsadm” command.

Sometimes I will encounter resumes where the job applicant puts “SharePoint Developer” or “SharePoint Administrator” in their work history but nothing in the roles and responsibilities indicate the degree of technical expertise required to be called a “real SharePoint Developer” or a “real SharePoint Administrator”! 

The point I’m trying to make is please, please, please–do not inflate your work experience, especially when applying for jobs. You might fool the recruiters but you’re not going to fool the technical leads. Please be honest in your resumes because people will catch you if you think the inflated titles will make you a better candidate for a job.

Honesty people!