Installing SharePoint 2010 on Windows 7

I installed the public Beta of SharePoint 2010 on Windows 7 last night. There were several resources on the web to use as a guide, I found this one to be the best:

Setting Up the Development Environment for SharePoint Server

There are a couple main points you need to be aware of:

  • The setup contains a config file that must be edited to allow SharePoint to be installed on a Windows 7 or Vista
  • There are several prerequisites required before you install
  • There are a few hotfixes required after the install but before running the SharePoint Configuration Wizard
  • Install Visual Studio after you install SharePoint (this isn’t in the guide)

Change SharePoint Service Accounts

Change SharePoint Central Administration Account

  1. On servers running SharePoint Central Administration site run the following command:
    stsadm -o updatefarmcredentials -userlogin DOMAIN\USERNAME -password PASSWORD
  2. On other servers not running SharePoint Central Administration site run the following command:
    stsadm -o updatefarmcredentials -userlogin DOMAIN\USERNAME -password PASSWORD -local
  3. Run iisreset /noforce to restart IIS
  4. To make sure that this operation completed, open SharePoint Central Administration site >> Operations >> Timer job definitions and wait until Administration Application Pool Credential Deployment timer job disappears from the list.

Change Application Pool Accounts

There are two ways to change application pool accounts in SharePoint: first one using GUI, and the second using STSADM command. To change application pool accounts using GUI:

  • Open SharePoint Central Administration site >> Operations >> Service Accounts (under Security Configuration section)
  • Select Web Application Pool option and pick Web Service and Application Pool you would like to make changes to
  • Enter username and password for application pool service account.
  • You need to do this for each application pool account you would like to change on every SharePoint server in your farm

To change application pool account using STSADM command, run:

stsadm -o updateaccountpassword -userlogin DOMAIN\USERNAME -password PASSWORD –noadmin

Once again, you need to do this for each application pool account you would like to change on every SharePoint server in your farm.

There is also a third way to change application pool account – using LaPointe's custom STSADM command extensions: http://stsadm.blogspot.com/2008/10/changing-application-pool-identity-via.html

To change application pool account for SharePoint Central Administration web application run:

stsadm -o updatefarmcredentials -userlogin DOMAIN\USERNAME -password PASSWORD

 

Change Windows SharePoint Services Help Search account

To change Windows SharePoint Services Help Search account, run:

stsadm -o spsearch -farmserviceaccount DOMAIN\USERNAME -farmservicepassword PASSWORD

Change Default content access account (used by the Windows SharePoint Services Help Search service)

To change Default Content Access account, run:

stsadm -o spsearch -farmcontentaccessaccount DOMAIN\USERNAME -farmcontentaccesspassword PASSWORD

Change Office SharePoint Server Search service account

To change Office SharePoint Server Search account, run:

stsadm -o osearch -farmserviceaccount DOMAIN\USERNAME -farmservicepassword PASSWORD

Change Default content access account (used by the Shared Service Provider)

To change Default Content Access account, if the Infrastructure Update for Microsoft Office Servers is installed:

  • Open SharePoint Central Administration site, click on your Shared Services Provider (in the Quick Launch, in the Shared Services Administration group)
  • On the Shared Services Administration page, in the Search section, click Search Administration.
  • On the Search Administration page, on the Quick Launch, in the Crawling section, click Default content access account
  • On the Default Content Access Account page, in the Account box, type the domain and user name for the account (in the form DomainName\UserName)
  • In the Password and Confirm Password boxes, type the password for the account.
  • Click OK.

To change Default Content Access account, if the Infrastructure Update for Microsoft Office Servers is not installed:

  • Open SharePoint Central Administration site, click on your Shared Services Provider (in the Quick Launch, in the Shared Services Administration group)
  • On the Shared Services Administration page, in the Search section, click Search Settings.
  • On the Configure Search Settings page, in the Crawl Settings section, click Default content access account
  • On the Default Content Access Account page, in the Account box, type the domain and user name for the account (in the form DomainName\UserName)
  • In the Password and Confirm Password boxes, type the password for the account.
  • Click OK.

You can also use crawl rules to specify a different content access account or authentication method, read more at http://technet.microsoft.com/en-us/library/cc263052.aspx.

Change Shared Service Provider Service Accounts

To change Shared Service Provider Service Accounts, run:

stsadm -o editssp -title SHAREDSERVICESPROVIDERNAME -ssplogin DOMAIN\USERNAME -ssppassword PASSWORD

You need to run this command on every SharePoint server in your farm.

Change Excel Services Account

To change Excel Services Account:

  1. Open SharePoint Central Administration site, click on your Shared Services Provider
  2. Click edit Excel Services settings
  3. Enter username and password for the Excel Calculation Services account and then click the OK button.

Change Profile Access account

  1. Open SharePoint Central Administration site, click on your Shared Services Provider
  2. Click User profiles and properties
  3. Click Configure profile import
  4. Enter username and password and then click the OK button

SharePoint deployment jobs are off by 3 hours

One of the beautiful things about SharePoint is that you can schedule the time when you want your solution to be deployed or your page to be published. Recently, I have noticed that on one of our SharePoint farms, all deployment jobs were off by 3 hours. Naturally, I suspect that this problem must be caused by time zone misconfiguration. Obvious, right? What wasn't obvious is that to get this problem fixed you have to make sure that your time zone settings match in three separate places:

  1. Under local regional settings on your server (Do'h)
  2. Under Web Application General Settings (in SharePoint Central Administration >> Application Management). Ideally, all your web application will use the same time zone.
  3. Under Regional Settings in Site Settings for the specific site you're working with.

 

I realize that this is fairly small and easy to fix problem. But I just hate these annoying little problems that interrupt my afternoon nap... now back to sleep, I mean work J

Naming Conventions can be Your Enemy

Or your ally in the fight against technology management.  Earlier this week I was given the task of doing some naming for new servers, which is pretty much SOP.  Problem is, we don’t have a naming standard.  As such, I may choose a name that annoys someone, or they choose a name that annoys me.  This becomes very political.  We don’t want to name things in such a way that they annoy people.  It’s a bad idea.  And, much to my dismay, I said something this morning that was pretty much just insulting to one of my team members.

I could have given loads of excuses, but it wouldn’t have mattered.  I was being petty.  Man, that’s a bad idea in an office.  It divides teams, and man, that’s *really* bad in an office.  The reason it came about was because a few people were talking about moving into “fun” server names, as apposed to functional server names.  Examples of this would be Cygnus or Badger, as apposed to GR-SQLCluster1.

The reasons behind it being:

  • It’s more secure if the attacker doesn’t know what the server does, based on it’s name
  • Server roles change over time, so GR-SQLCluster1 might become relegated to an apps server
  • Sections of functional names become redundant
  • Organize names by type; i.e. birds, galaxies, different words for snow, etc

At first glance, they make great sense.  However, after a little time to digest the reasons, a few things become clear.

  • If an attacker is able to get to the server, to the point that they can know the name, you are already screwed
  • A good practice is to rebuild the server if it changes roles, and with that change the name
  • People don’t want to connect to the Badger Server
  • You need a reference list to figure out what the Cygnus server does/where the Cygnus server physically is
  • If you want to create DNS entries to provide functional names to it, that’s another level of complexity to manage
  • What happens when you run out of server names?

Given this list, it now becomes an interesting debate.  But I have one question for you:

As a developer, would you name a variable ‘badger’ if it was holding a shopping cart?  Not a chance.  You would only do that if it were badger related, and even then you are better off with ‘meanLittleWoodlandCreature’ in case you change something.

In my response I called the security reason laughable.  Again – petty and a really, really, really bad idea when in a team discussion.  Obviously I was in a pissy mood for some reason, or maybe a greater than thou mood thinking I knew more about the topic.  I tend to do that.

I think what really made me do it was that we are developers, not administrators.  It’s not our job to name servers.  So why were we?  I didn’t want to piss anyone off, I just wanted to name the server so we could move on to the next stage of the deployment.  This situation could have easily been averted.

If we had a naming convention for our servers, regardless of fun vs functional, I could have followed the convention and washed my hands of the problem.  So I guess the question is, why don’t we have one?  Lot’s of companies don’t have them.  And I think it’s because of stagnant server growth.

If you are only setting up a couple servers every so often, you aren’t bogged down with these types of questions.  You have time to discuss.  The problem we are having, I think, is because we have increased our server growth dramatically in the last little while, which hasn’t given us enough time to discuss names as a group.  I was rushing to get the server into production because the administrators were busy working on other tasks that were filed under the category “Do Now Or ELSE!”

So I think we need a naming convention.  A functional naming convention.  It will prevent a world of hurt down the road.  Now to get buy in, and ask for forgiveness.  I still have lots to learn.

Building public-facing websites using SharePoint 2007: SEO best practices

This is a fourth and final post of the blog post series on building public-facing websites using SharePoint 2007. The first part was dedicated to the planning building public-facing websites using SharePoint 2007. The second part was dedicated to custom branding and development in SharePoint. The third blog post of the series was dedicated to search functionality in SharePoint. Let's start...

 

PAGE CONTENT

To me fresh and relevant content is the single most important aspect that defines your SEO rankings. You must strive to keep the content of your website fresh and read worthy. Take advantage SharePoint workflows and content expiration features to make it easier to generate new content. And, yes, having more text on the page is better than having more images.

Page Title is very important from SEO perspective. It absolutely must be descriptive and to the point. If you have to add your company name to the page title, add it to the end of the page title and separate it with double dashes "--" or something. Please try to avoid naming all pages in the site with the same page title.

Page Description must clearly summarize in one or two sentences what the page is about.

Even though keywords are not as important as they used to be (partially because keywords have been abused in the past.) So, it's up to if you want to use them or not. Personally, I don't.

 

PROPER HTML TAGGING

From my experience, the following HTML tags are important from SEO perspective:

  • H1, H2, H3 ….
  • Title
  • Alt parameters for IMG
  • META tags (maybe)

 

SEO-friendly URLs

Having SEO-friendly URLs is one of the easiest ways to get higher SEO rankings. As long as your page URL contains relevant keywords your page will have high(er) SEO ranking. It is amazing how something this simple can be so important. Use Imtech SharePoint SEO Slugs Feature to get Sharepoint build SEO friendly URL automatically when you create new page(s).

 

Sitemaps and robots.txt

Sitemap is a simple XML file describing the structure and the hierarchy of your website a search engine. It also provides the mechanism for letting search engines know when your pages have been added, removed or otherwise modified. You are supposed to use update your sitemap file every time you add a page, and ideally you should do that for every major search engine. To make things easier, use SharePoint SiteMap Generator.

As with any other public facing website, you should add robots.txt to your website to make sure that search engines do not crawl the sections of the site that you do not want them to. Here is an example of robots.txt file:

User-Agent: *

Disallow: /Search/

Disallow: /_layouts/

Dissalow: /ReusableContent/

Dissalow: /WorkflowTasks/

Dissalow: /SiteCollectionDocuments/

Dissalow: /SiteCollectionImages/

Dissalow: /Documents/Forms/

Dissalow: /Pages/Forms/

 

sitemap: http://www.SHAREPOINTSITE.com/sitemap.xml

 

 

Handling page redirects properly

It is very important to properly handle all your 404 errors. If you have any pages that have been moved or deleted, you must properly handle the HTTP request using URL rewriter and 301 permanent redirects. Here is a sample of the code from MSDN how to do that: http://msdn.microsoft.com/en-us/library/cc721591.aspx

To verify that your URLs return proper HTTP header, use URI Valet.

 

Handy SEO tools for SharePoint

  • Imtech SharePoint SEO Slugs Feature: Imtech SharePoint SEO Slugs is a SharePoint Feature which hooks up to the Create Page Application Page provided with MOSS 2007. While creating a slug it not only separates all the different words with a hyphen (-) but also removes all the stop words as well!
  • SharePoint SiteMap Generator: the process of keeping your site's sitemap.xml file current
  • URI Valet: an online tool to check what HTTP header your URL returns.

 

As I have already mentioned in my previous blog post, ObjectSharp has been working with SharePoint technologies for years now: building public facing websites and intranet for clients, developing custom SharePoint web parts and features, designing custom templates, and so on... Oh yes, I forgot to mention hundreds of hours of SharePoint training (public and private) for developers and power users that we have taught to our clients. So, if you need any help customizing your SharePoint in any way, please email our Client Services Manager, Gisele Bourque, at gbourque@objectsharp.com, and/or if you need any training on SharePoint technologies email our Training Manager, Julie James, at jjames@objectsharp.com. Or visit our new and fancy SharePoint-based website at http://www.objectsharp.com.



Related resources:

Stop Complaining About Software Expenses

It’s been a long week, and it’s only Monday.  It all started with an off-the-cuff comment.  It was of the petty nature, and it certainly wasn’t accurate.  It seems that is usually the case with petty comments.

I was berated for suggesting SharePoint Services as a replacement for our ageing intranet, and the commenter responded with a quick “SharePoint?  Microsoft makes that, it’ll cost too much.  Our current java site works just fine, and it’s free.”  Or something of that nature. 

How do you respond to a petty comment?  It’s pretty damn hard:

  1. While Microsoft Office SharePoint Server 2007 does cost money for licensing, Windows SharePoint Services 3.0 (which MOSS is built on) is free.  Not free as in speech, but free as in beer.  Always has been. 
  2. Java is a terrible language for websites.  It’s slow, and none of the developers in the company know Java.  We all program with .NET languages.
  3. The current intranet is running on an AS/400.
  4. The bulk of the stuff we do on our current intranet could very easily be done in SharePoint, without any development.  And, we can also increase productivity with the added features of team workspaces and free templates for other departments.
  5. The only cost will be in man-hours setting the server up, and migrating content.

Those have been my main arguments since I started working here.  We are a Microsoft shop, but very often choose non-Microsoft products.  Hmm…

The main reason we don’t use Microsoft products is cost.  Plain and simple.  Ironically, that is also the same reason WHY we use Microsoft products.

We use SQL Server, Windows Server 2008, Active Directory (finally!), IIS, MOSS (soon), and program in C#.  We don’t use office 2007, only Office 2003, some computers are still on Windows 2000 and XP.  Only one computer is running Vista, and two are running Windows 7.  But then again, we are a Not-For-Profit company.  Budgets are tight.

This post is NOT a comment on our current state of technology, because like I said in a previous post, we do a pretty good job of staying on the cutting edge in a few cases.

This post IS a comment on the people out there who think cost is the only thing to look at when evaluating a product.  For the love of god, STOP bitching about price.  START bitching about quality.

I can’t stand bad software.  People don’t pay for good software, but then complain about its quality.  Come on!  There is a formula out there that calculates the cost of a piece of software over time.  It takes into account initial cost, and the cost of the updates that follow.  It’s a simple y = mx+b formula.

Now, when you have a higher initial cost, you tend to assume it’s of higher quality.  Put this into the equation, and the number of updates, and the cost to implement these updates goes down.  Over the life of the product, it’s cheaper to go with the software that is initially more expensive.  This is basic business.

What this basic business formula doesn’t show you is the added headaches you get with crappy software.  You tend to end up with silos of systems, and silos of data.  You don’t get integration.  This is where the cost sky rockets.  Or more accurately, this is where productivity decreases.

Ironically…

SharePoint Services 3.0 is free.  It doesn’t cost anything to use.  It’s easy to use, and integrates with most of our internal systems.  I just ruined my entire argument.  Sorta.  SharePoint is a quality piece of software, and over time, it will cost less to use and maintain than any of the other intranet/middleware applications out there.  Most people don’t realize this.

I’ll probably get flack for this one:  Most people don’t complain about software expenses.  They complain about Microsoft expenses.

  • “We give Microsoft too much money, and don’t get enough in return.”
  • “There must be better software vendors out there than Microsoft that are cheaper.”
  • “Why bother upgrading; XP Works fine.”

Have you seen the cost of a friggen Oracle license?  What about IBM’s iSeries?  Novell’s Groupwise?  My jaw dropped when I saw the cost of these things.  I can’t say a single nice thing about Groupwise.  It’s a terrible product.  IBM’s iSeries is pretty good, but it’s limited what you can do with it.  Oracle knows databases, but has a higher license cost than a good chunk of a department’s salary.

Microsoft gets most of our money because it has quality products, at a good price.  Look at a few competing vendors products and compare cost and quality as well as the ability to integrate across platforms.  Revelation is a wonderful thing.  You might think twice before settling on cost.

Silverlight 3.0 and Why Flash Still (unfortunately) Won

Last week Silverlight 3.0 was released.  In Toronto, ObjectSharp put on a very cool launch event, with lots of great demos and compelling reasons to start using Silverlight immediately.  I was impressed, but I’m a Microsoft fan-boy (fan-boi?), so that doesn’t count.  It was certainly fitting that ObjectSharp propose using Silverlight for some parts of our new website www.woodbineentertainment.com, seeing as they won the bid to build the new site.  I saw the potential; as did a few others on the team.  However, some executives did not see the benefit.  I respect their opinion, somewhat because I have to – they can fire me after all, and mostly because they have business sense on their side.

The company is very much on the cutting edge of technology in a few respects, but very conservative in the way we choose technology.  For instance, our new site will be built on Microsoft Office SharePoint Server 2007.  I’d wager there are less than a hundred publically facing websites on the internet that use MOSS (probably due to complexity and cost), yet we chose to use it because of the potential in further developing it in future iterations.

Silverlight on the other hand is a different story.  Recent reports peg Silverlight penetration at around 25-30% of all browsers.  Whether or not this is accurate, who knows.  It’s the only data available.  Flash penetration is at 96%.  Now, in my opinion 25% growth in 2 years on Silverlight’s part is impressive.  Flash has been around for nearly 2 decades.  There is definitely a correlation to be made in there somewhere.

At this point, I was sold on using Silverlight.  The exec’s still weren’t.  Seeing as Silverlight is a browser plug-in, it must be installed in some way, shape, or form.  At 25%, that means our customer demographic would have around 10% penetration.  That is terrible.  Getting them to install a plug-in to view site content is a tough sell.  The executives didn’t want to scare away customers by making them install the plug-in.  SharePoint doesn’t need a browser plug-in.

And here in lies the Catch-22

To expand our marketed audience, we build on Silverlight to give them more content that is better authored to their needs.  In doing so, we lose customers because they need to install the plug-in.  There is no metric at this point in time to help us extrapolate the difference.  There is a reasonable risk involved with using such cutting-edge technology.  We will use it when browser penetration is high enough, yet browser penetration won’t grow if sites like ours don’t use Silverlight.

Ah Well

I’m a technology risk taker.  I live on the bleeding edge.  I run Exchange 2010 beta, on Server 2008 virtualized on Hyper-V, with IIS7 running this site, browsed by IE8 on Windows 7 RC, and authored in Office 2007 (2010 if Microsoft would give me the flippin bits!).  The company, not so much.  Risk is good – as long as you can mitigate it properly.  I can manage my risk, as it’s not the end of the world is something here crashes.  I don’t lose an audience.  If the company can’t market to it’s customers because the tools in use are too new, it will lose audience.  Period.  And that means lost revenue.

Maybe we can convince the exec’s in Phase II.

Join ObjectSharp for Silverlight on the Silver Screen – July 9 – Scotiabank Theatre Toronto

Silverlight 3 will soon be released.  And to properly celebrate the excitement of its release, ObjectSharp is teaming up with Microsoft to present an action-packed first look at the UX3 platform, live from the Scotiabank Theatre in Toronto. 

As one of the first companies to be featured on Microsoft’s Silverlight gallery, our consultants will share with you their deep knowledge of the next generation of tools.  Whether you are a designer, developer, or purely a marketing geek, you will not want to miss this blockbuster event.  You will see feature-rich demonstrations of Silverlight, Expression Blend, SketchFlow, and  Windows 7 touch technology.  You will also see how these tools can be used to dazzle your customers and gain attention for your brand.

 

 

 

 

 

 

For Developers and Designers:

  • See in-depth demonstrations of Silverlight 3, Expression Blend, and Windows 7 touch technology.
  • Learn how to quickly design user interactions with Microsoft SketchFlow
  • Take Designer/Developer work flow to the next level with Visual Studio Team System
  • Learn how to cut off your bosses head off and paste it on other people’s bodies with Expression Studio

 

For CTOs and Marketing Managers

  • Understand the benefits of creating line-of-business applications with Silverlight and .NET RIA Services
  • Learn how to integrate Rich Media and Advertising with the Microsoft Platform
  • See Touch technology and natural user interfaces bring kiosk applications to life with Windows 7 and WPF

Technologies You Will See:

  • Silverlight 3 featuring WPF & XAML
  • Expression Blend 3 featuring SketchFlow
  • Windows 7 featuring Touch
  • Microsoft Office SharePoint System 2007 (MOSS) for external facing web sites
  • Visual Studio 2010 Team System

Register Online   |   Watch the Movie Trailer

Security, Architecture, and Common Sense

Good enough is sometimes not good enough.  I’ve been doing a lot of thinking lately (well, I’m always thinking), and security has been an issue that has come up a lot.  Frankly, I’m a two-bit software developer.  I know my code isn’t the best, nor the most secure.  I use strong passwords, encrypt my sensitive data, and try to limit access to the applications for those who need to use it.

In theory this works.  Problem is, it’s a lame theory.  There are so many unknown factors that have to be taken into account.  Often times they aren’t.

When I go to build an application I spend time designing it and architecting it.  This is usually the case for most developers.  What I’ve noticed though, is that I don’t spend time securing it.  I can’t.

Imagine building a house.  You put locks on the doors, bars on the windows, and someone breaks in.  Why?  Because someone left the key in the door.  You can’t build against that.  You just can’t.

You can follow the Security Development Lifecycle, which I recommend to each every single developer I meet.  There are tons of resources available.  But it can only go so far.  It’s designed more for being part of the iterative processes, not the architecture.  Or at least, that’s how most people interpret it.

So?

My last post talked about Single Sign-On (SSO).  It’s a great sellable feature for any product.  What most people don’t realize though is the inherent security benefit to it.  With it, that means one less password to remember, one less password that could get intercepted, one less password to change every month.  This is a fundamental architectural issue.  But at the same time, it’s common sense.

What is sometimes the simplest idea, is usually the correct solution

What the hell does that mean?  It means keep it simple.  Security is simple.  Keep data from prying eyes, and keep it from getting lost.  This is common sense.

Security is not difficult to comprehend.  It becomes difficult when academics get involved.  Spouting theories and methodologies scares people into thinking security is extremely difficult to implement.  It’s not!

Follow the Data

Understanding the flow of data is crucial in properly architecting an application.  It’s crucial in properly securing an application as well.  SSO is a perfect example of this.

The SSO feature in Office SharePoint Server 2007 maps user credentials to back-end data systems. Using SSO, you can access data from server computers and services that are external to Office SharePoint Server 2007. From within Office SharePoint Server 2007 Web Parts, you can view, create, and change this data. The SSO feature ensures that:

  • User credentials are managed securely.

  • User permission levels that are configured on the external data source are enforced.

It makes perfect sense.  It’s simple when you think about, and it affects every subsystem of SharePoint.  Make security a feature.

My first TSPUG presentation on how to build public facing websites using SharePoint

On June 17, 2009, I will have my first talk at Toronto SharePoint User Group. The topic of the presentation is "Using SharePoint for Public Facing Websites". This presentation will cover (or attempt to cover) the best practices for building public facing websites using SharePoint, as well "gotchas" that I have came across working with SharePoint over the years. If interested, please come along…

Toronto SharePoint User Group usually meets 2 Bloor Street West, 12th Floor, Toronto (Bloor-Yonge subway station). Attendees tend to arrive at 6pm, grab a bite and socialize, meeting starts at 6:30 with Q&A, and the presentation starts by 7pm. The presentation wraps at about 8:20 or 8:30 and we end with prizes for the last 10pm. Some people get together for a beer after the meeting, but it's optional…

Please RSVP to Susie Ibbotson at sibbotson@nonlinear.ca if you're coming, in order to make sure that we order enough pizza J