View SharePoint 2010 List in Datasheet View

Wasn’t this the version of SharePoint and Office when everything seamlessly worked on the first try? Not so! It turns out Microsoft wanted to provide just one more reason to upgrade to the next version.

I am trying to view a list in my SharePoint 2010 site and received an extra generic error message. (What is more generic than “Unknown Error”? How about a message that lists three potential issues none of which provide details.”) This is the error message I kept getting in popup wind style.

image

[The list cannot be displayed in Datasheet view for one or more of the following reasons: A datasheet component compatible with Microsoft SharePoint Foundation is not installed. Your Web browser does not support ActiveX Controls. A component is not properly configured for 32-bit or 64-bit support.]

The issues turns out to be that 64-bit versions of Office 2010 does not contain an important Datasheet component to allow the proper view. This is according to Microsoft’s knowledge base article 2266203 from July 2, 2010 which can be found here http://support.microsoft.com/kb/2266203.

Microsoft provides two solutions for the issue. The first solution is to only use 32-bit Office, unless you must have the benefits of 64-bit. (HUH? I thought the big push was to move toward 64-bit processing and programs.)

The second solution involves installing the 2007 Office System Driver: Data Connectivity Components from Microsoft Downloads at http://www.microsoft.com/downloads/details.aspx?familyid=7554F536-8C28-4598-9B72-EF94E038C891&displaylang=en.

As I am running 64-bit Office I tried the second solutions, after the 25 MB download and about 2 minute install time, I was up and editing my lists in Datasheet view.

Advertisements

Create a Managed Account out of a Local User

Since I am a glutton for punishment according to my wife, (I see nothing wrong with long runs in the heat of the day or multiple hours of intense Ultimate Frisbee in 30 degree weather) I have been building a single server SharePoint 2010 farm using local user accounts. That’s right, no silly Active Directory for me.

As I noted in my Installing SharePoint 2010 with Local User Accounts blog post there is a trick to getting around creating the configuration and content databases because you lack a real domain, and the solution being PowerShell.

The next thing most of us try to do after a successful install is to setup site collections and service applications. But to do this you must setup a new web application. I’ll leave you to find your way there through the Central Admin, your smart I know you can do it.

As you setup a web app you will be asked to use the default security account, Network Services, or a custom account to run the application pool under. If you like me you would prefer to use a specifically identified account.

So you’ve clicked Register New Managed Account because the custom service account you’ve created is not listed, and guess what you get an error.

image

Which read “The specified user is a local account. Local accounts should only be used in stand alone mode.” What is a person to do?

PowerShell to your rescue! There is a set of cmdlet called SPManagedAccount.

The first step is to register the desired account as a managed account via New-SPManagedAccount. You will be prompted to enter the users credentials: <domain\computer name>\username and password. (The computer name is very important as part of the credentials.)

The Set-SPManagedAccount (http://technet.microsoft.com/en-us/library/ff607617.aspx) allows for you to further customize or reset the password and assignment of the managed account.

Now you can try to create the Web application or other object which requires a managed account, and in the dropdown you will see your newly registered account.

SharePoint 2010 Index of PowerShell Cmdlets

For those always searching for a fairly complete reference to all the built-in SharePoint cmdlets TechNet has them listed at:

http://technet.microsoft.com/en-us/library/ff678226.aspx

Hopefully this will help someone along the way with a quick find.

SharePoint 2010 Comparisons

A quick mid-week post, which is more for my own benefit than others. (I know that is pretty selfish of me, not worried about the reader…but I truly worry everyday about you the reader, not finding the information you need when you need it.)

This link has made its rounds at least once already around the blogosphere as well as the Twitter field, but it never huts to reprint it one more time.

Microsoft has put out an excellent interactive RIA showing the breakdown and differences between SharePoint Foundation Server, SharePoint Server with Standard CALs, and SharePoint with Enterprise CALs.

The site even goes as far as allowing you to filter based on one of the six parts of the SharePoint doughnut.

SharePoint 2010 Comparison (http://sharepoint.microsoft.com/en-us/buy/Pages/Editions-Comparison.aspx)

Here is a screen clip of what it looks like:
SharePoint Comparison Clip

Installing SharePoint 2010 with Local User Accounts

This morning I awoke early to a lovely fall-esque morning, bright sun, clear sky, and just a little chill to the air…you never would have thought it was mid-August.

So a beautiful morning, mixed with a delightful cup of coffee (Wegman’s Cinnamon Nut coffee blend) seemed like the perfect fit to write an article on how to install SharePoint 2010 on a local virtual machine with domain connections for development.

So gather you cup of choose beverage ( I recommend a Bell’s Double Creamy Stout for an evening session of install, but I’ll leave that for you to decide) grab the machine of choice and let us begin.

I can’t claim to know it all, and have borrowed the notes made by Neil ‘The Doc’ Hodgkinson in his article from October 19, 2009 found at, http://sharepoint.microsoft.com/Blogs/fromthefield/Lists/Posts/Post.aspx?ID=112.

My first time attempt at performing an advance install of SharePoint 2010 on a single machine, I ended up with the following error message:

clip_image002

(For the search engine: The specified user <local user> is a local account. Local accounts should only be used in stand alone mode.)

So reading this message, I then uninstalled and tied again, but this time using the Stand Alone option given at install time. Well, this worked…BUT you end up with a special SQL Express version installed on your machine, and no control over what user accounts are performing what actions. This was not ideal for me, nor did it give me the additional practice of SharePoint farm installation that I was seeking.

So enough of the small talk…onto the How To!

  1. The first step is to plan out the appropriate user accounts that will be needed throughout the installation process.
    • Based on guidance found in MSDN and the SharePoint Getting Started Guide (http://www.microsoft.com/downloads/details.aspx?FamilyID=3ba69d42-65a2-48fb-88d9-814034874498&displaylang=en) there area number of different user accounts that can be created and assigned to different tasks, in general I would recommend creating the following three accounts.
    • SQL Server Service Account
      • Purpose: Default account used to run the SQL Server services
    • Setup User Account
      • Purpose: Runs the Setup, SharePoint Products Configuration Wizard
      • Specific Requirements: Must be part of the Administrators group, and have read/write access to the SQL server. In addition this account should have db_owner rights in SQL so that PowerShell can be leveraged to get around the noted local account issue.
    • Server Farm and Database Access Account
      • Purpose: Configure and manage the server farm and acts as the app pool identitiy for Central Administration.
  2. Place the DVD into your system or mount the ISO you have. The following opening screen shall come up. Click Install software prerequisites to begin with to confirm all the needed items are installed.
    • clip_image004
  3. This is the opening screen to the prerequisite checker.
    • clip_image006
    • Click Next
    • This will run for about 10 minutes depending on what will need to be downloaded and installed. It is possible to pre-download the above items and install before running the pre-requisite checker.
  4. Click Finish. You will be returned to the opening screen.
    • Click Install SharePoint Server
  5. Enter your Product Key and click Continue.
  6. You are now prompted to either perform a standalone or a server farm install.
    • clip_image008
    • Select Server Farm. Stand alone will create the local SQL version, etc…
  7. Under the Server Type options, you should select Complete as it provides the ability to properly customize the installation.
    • clip_image010
    • Click Install Now
  8. Once the installation completes, you will be asked to launch the Configuration Wizard. DO NOT just blindly click Close. Uncheck the box that says "Run the SharePoint Products Configuration Wizard now." If you don’t the local user account error message will be displayed.
    • clip_image012
  9. Exist out of the Install screen by clicking Exit.
  10.   Now the product is installed, but nothing has been setup and configured. Why? Because we have delayed the running of PSConfig so that we could use local user accounts, instead of being attached to a domain controller.
    • This is were Neil’s blog article comes into play. His article can be found at http://sharepoint.microsoft.com/Blogs/fromthefield/Lists/Posts/Post.aspx?ID=112.
    • SharePoint 2010 has been integrated into PowerShell with a collection of administration cmdlets, more on this in future posts, some of which we are use to seeing as part of STSADM, and even some new ones.
    • For our issue we will need to use New-SPConfigurationDatabase cdmlet. This cmdlet creates a new configuration database on the designated SQL server, for a SharePoint Farm.
  11.   From the start menu open SharePoint Management Shell running it as Administrator this is required even if you are logged as a local administrator….this is a PowerShell prompt, with the SharePoint modules included, and enter New-SPConfigurationDatabase at the prompt and hit enter.
  12.   You will then be asked to enter the required information for a configuration database.
    • clip_image014
    • When prompted for the Farm Credentials make sure to include your machine name as the domain for the account and to enter the password. Passphrase is the password used of the login account.
    • If you receive any error messages, close out of the PowerShell console, delete the Admin and the configuration databases, if they exist, and try again. It does seem to take a few minutes for the process to complete.
  13. Once this succeeds launch the SharePoint Products Configuration Wizard. You will not get the normal opening screen, as we have already created the farm information via the above PowerShell cmdlet.
    • clip_image016
  14. Since the farm has already been created you will be shown the current farm settings. Make sure "Do not disconnect from this server farm." and click Next
    • clip_image018
  15. You will now be asked to configure the necessary settings for the Central Administration Web application for the new farm. Feel free to assign a new port or accept the default, just make sure to take note of what it is. As we will be using local user accounts through out this setup, NTLM is the preferred security setting.
    • clip_image020
  16.   After clicking Next, you will be given a chance to review the settings for the farm. If everything looks correct, click Next.
    • clip_image022
  17. Configuration will now begin, the green processing bar will fill back and forth completing the 9 tasks of SharePoint configuration. Upon completion of the 9 configuration tasks, you should see the "Configuration Successful" screen. Click Finish and the CA should appear.
    • clip_image024