Excel workbooks stop working after upgrade to CRM 4.0

My organization recently upgraded our Microsoft CRM environment from 3.0 to 4.0 - news to me all the Excel Services workbooks broke for certain users, even after I updated all the data connections and republished.  With help and lots of testing we finally figured out the issue.

All the users that had broken workbooks had not yet logged into CRM 4.0 and established a session - once they did and went back into SharePoint the workbooks connected and were refreshing data instantly. 

Very odd - but noted and fixed.

How to Install SharePoint Foundation 2010

I'm eagerly awaiting two new servers, as I prepare and go through the install/setup/configuration I will document all my steps here. Please check back....

How to Search by SharePoint ID

Initially this seemed like an odd request to me, but due the business reason behind it, it presented a unique challenge - that was very easy. Keeping in mind that SharePoint ID's are not unique, they are only unique to the list your working in so when you have several lists containing similar data a simple search could return several duplicate results, plus you would have to tweak the search in the SSP to accept a string of "ID=1234"

1. On each list create a new view or edit your default view to expose the ID field, make sure it is #1 in the column order.
2. *If you have Versioning enabled and Require Checkout on Edit - turn this off so you can add the Form Web Part.
3. On your view page, Site Settings > Edit Page > Add Web Part > Form Web Part - put it above your list.
1. By default you will end up with a text box and a "Go" button so you probably need to edit it to give users instructions to only search by ID.
4. Once you have the web part added, you need to Edit > Connections > List Name > Leave default > Leave default so it should have read T1 and ID
5. Edit > Modify Shared Web Part > Source Editor > paste in some HTML, for example mine is;

When your done, you will end up with something like this;

What is SharePoint Architecture?

I want to share a discussion that I started on Linkedin about a month ago.  It really helped me and I hope it will help others as well.  Next time someone asks you what SharePoint Architecture is or if you are a SharePoint Architect - think long and hard before you quickly answer "Yes!" and begin to explain.

View the original feed here.
Resources provided in the posts;

1. Two Key Roles and Requirements for SharePoint Farm Administration provided by: Yvette Caluya
2. SharePoint Job Descriptions - provided by: Veronica Palmer

My initial question: Just curious what "sharepoint architecture" means to you? People keep throwing this term around and I hear lots of fluff.

Responses:

• For me, SharePoint architecture means basically two things: 1. The infrastructure architecture consists of the physical and logical components (server, network, Active Directory, etc) that run SharePoint. 2. The informaiton architecture that organizes information (sites, pages, documents, lists, pictures, etc.) stored on SharePoint. People sometimes also mentioned application related architecture, like Workflow, when talking about SharePoint but when you consider SharePoint as a "platform", all applicaiton related architectures are actually on top of the SharePoint architecture...

• Well clearly that's someone who designs whole cities - or even whole states, made just out of SharePoint, no? :-)! Or could it be someone who designs custom SharePoint deployments?? I tend to think of someone working more on the "information architecture" side of things.

• When I think of SharePoint Architecture I think of almost everything I work with right now. How to build up the farms, what versions they run, how we upgrade and innovate them, how we deploy site collections and the processes around it, the integration with other applications, databases and data sources, the way people have to work with SharePoint and how we will support them in it, the helpdesks, the training, the future developments, etc etc etc. In other words, to me SharePoint Architecture is both technical and people-driven, based in the present and what we'll work to in the future over the coming years.

• Jennifer, Excellent question. In the very complex world in which we live, too many people use the same word for so many things. I am going to agree with Rob above, as I view an architect as someone who DESIGNS but does not necessarily implement a solution. While they need to understand the technical aspects of their recommendations and the implications of their design, I have found too many companies who want an "architect" to design something, then build. implement, and operate what they have designed, possibly never designing anything else in their lives. I think that's analogous to having an engineer design you a car, then drive Miss Daisy around and change the oil in it. So as a wrap up, Rob's answer hits it 100%

• Me too, I see it as vision and strategy dependent. The more complex the outcome the more complex it will be.

• I see architecture as relating to information architecture, taxonomy. Questions posed during architecture discussions i feel would be related to the type of portal implemetion whether it be an organizational based portal, task based portal, hybrid. Very seldom when asked about sharepoint architecture by clients do i find them asking me about the architecture of the farm itself, whether it be a medium farm with five server, two WFE's, etc..

• Functionally speaking Rob is quite right and technically speaking, Microsoft defines the scope of SharePoint information worker into two separate domains; however they are interrelated at some level. SharePoint Configuration and SharePoint Development. As certified person, SharePoint Architecture is surly wear of configuration also he is the person responsible of any integration\governs activities. By Integration is like: Windows SharePoint services, are base platform for other application as well (E.g. Project Server), architectures real word scenario is to take benefits of the available WSS and plan integration required SharePoint solution, rather than implementing distinct environment. By Configuration is like: optimizing for geographical implementation when bandwidth is the bottle nick. By Governs -this is big section but an example- is like: business process translation.  Architectures domain starts a level out of SharePoint environment space, while developers are in.

• The question is not on who does what but what is SharePoint Architecture, am I correct? For me, SharePoint Architecture is the entirety of the Application Design. From Planning a farm to DR plans - Design of an end-to-end SharePoint Solution. Whether the requirement is DMS, Intranet/Extranet, Workflow, Portals, etc. In these days where management goes for a staff who knows it all - working within specialites is obsolete. I found this link and would like to share Key SharePoint Roles. For someone who has much interest in SharePoint you could be lucky if you can perform both:

• Hi Jennifer, I also compiled a series of SharePoint job descriptions that may help you in your quest, one being a SharePoint Architect.

• The "what is an X architect?" questions are very common; I have seen dozens of them in various groups and all produce a plethora of interpretations and opinions. There's no single definition of an architect, nothing that will apply for every company, and SharePoint architects are no different regardless of the guidelines from Microsoft. Some architects focus on infrastructure, while others focus on applications, integration and governance. Some are strictly IT focused while others blend into the enterprise architecture role, which usually has a business domain element involved. It depends on the needs of the organization. But that's a good thing, because an architect role, regardless of the specific platform focus, should be less of a task-doer and more of a designer, planner and big-picture thinker...someone who can envision the solution as a whole and how it relates to the enterprise, both in terms of IT strategy as well as relevance to the business needs. So both Rob and Alexander collectively nailed it.

• I expect the meaning depends very much on the context. Often people will have a comparison with something else in mind. In that case they will be referring to 'Sharepoint Architecture' as opposed to X architecture. And the level they are talking about (OS, application architecture, applications themselves, metadata etc) will depend on their role (eg system administrator, developer, knowledge manager).

• I've seen many different job descriptions all describing an "Architect". I would have to agree with Cole on the fact that an architect is more of a designer, planner and big picture person.

• Metadata is the application, SharePoint Architecture means that if you have consistent metadata, you can integrate all of your applications (Why do you think they came out with the term store?). Metadata is the key to everything because it drives consistency. SharePoint architecture is the combining of the unstructured (Formerly known as file shares) with the structured (DB apps) to drive business value.

• How did a question about SharePoint architecture turn into a question about what a SharePoint Architect is? Here's my 2¢. On it's most basic level, SharePoint architecture is the functionality and capabilities provided by the core Windows SharePoint Services (WSS) application framework. It enables collaboration, document management, content management and basic search, among other things. MS SharePoint Foundation has replaced WSS as the core SharePoint architecture in 2010. MOSS and now SharePoint Standard/Enterprise are ASP.NET applications built on the core architecture provided. Since SharePoint is meant to be extensible, you could rightfully say that the architecture consists of a set of core functionalities built on an IIS web application, utilizing an SQL server backend, and a middle tier management server. Since all of these functionalities can exist on one machine, it demonstrates that the SharePoint architecture is more than the hardware that defines a particular implementation. Someone mentioned Workflow. While the core SharePoint application provides simple workflow, it only takes advantage of the Windows Workflow Foundation (WF) and Windows Communications Foundation (WCF) frameworks already available on the Windows Server.

• David you said it all. That has to be the most complete technical explanation of what is SharePoint 2010 I have seen. May I use it on my clients?

• Greetings All, From my perspective, having experienced all aspects deteailed by her description, Ms Yvette Caluya has the most accurate interpretation: "......The question is not on who does what but what is SharePoint Architecture, am I correct? For me, SharePoint Architecture is the entirety of the Application Design. From Planning a farm to DR plans - Design of an end-to-end SharePoint Solution. Whether the requirement is DMS, Intranet/Extranet, Workflow, Portals, etc. In these days where management goes for a staff who knows it all - working within specialites is obsolete. I found this link and would like to share Key SharePoint Roles. For someone who has much interest in SharePoint you could be lucky if you can perform both: " A SharePoint deployment of any organization in excess of 200 users must certainly be well thought out or it is destined to perform poorly; its architecture must be planned carefully considering all the elements as mentioned by Mr. Bermawi

• True a good point; There was a great deal of technical explanations here of what SharePoint Architecture is. Which looks like solid Tech Stuff. A final requirement of the SharePoint Architecture has to aligned to the business need that resulted in the deployment of the product.

Cisco Quad vs SharePoint 2010 & Social Collaboration

I was introduced to Cisco Quad today, see the video here. My initial thoughts were wow Cisco must be confused because they created functionality similar to SharePoint 2010 My Sites. Makes you wonder if anyone over at Cisco has seen the new 2010 functionality? For the last two years I've heard how Cisco is trying to break into the market place and try to compete with SharePoint.....First with the integration with WebEx Connect & Meeting Place - let me tell ya that POS kills my machine each time I use it. To this day I prefer straight up Meeting Place. Anyway getting off topic. I like to see competition, but I don't see an advantage just yet. I imagine Cisco will eventually get the idea and learn it needs to INTEGRATE with SharePoint and not compete. I see a few advantages of Quad, if you are Cisco centric organization using UC products great - you can call each other from inside Quad and avoid long distance charges, awesome...I guess. I'm tired and this post isn't well thought out, but I can't wait to start working with Quad and see what type of integration Cisco offers within SharePoint, if any. You would think they know SharePoint is a $1 billion dollar product.... I'm still unclear if Quad is web based or client based? I will be open to it, however I'm loyal to my Microsoft products and if it doesn't exist - build it or integrate it. If you plan on upgrading to SharePoint 2010 you have all the social networking you need, even if you have Cisco UC - integrate that with you OCS, bring OCS into SharePoint and bam you can make calls from inside SharePoint...how hard was that? Overall I really feel like this will be a tough sell for Cisco when working with existing hard core Microsoft clients. Depending on an organizations upgrade path this might be beneficial for someone who plans to be on SharePoint 2007 for the next 5 years.

Has anyone actually worked with Quad? I'd really like to explore it more.

VSeWSS 1.3 nightmare

As I'm casually sitting around on a Thursday I decided to start making some custom web parts so I installed the Visual Studio 2008 extensions for SharePoint on my dev server (Windows 2003, running MOSS 2007 sp2).

I started with the good ole' Hello World Web Part, easy - great - done - deploy and ERROR. The error logs can be found on C:\Documents and Settings\Default User\Application Data\Microsoft\VSeWSS 1.3

1st error I get is: Microsoft.SharePoint.Tools.WebNotFoundExeception: No SharePoint site exists at the specified URL. - Go back into the project properties > debug tab > URL I changed the URL from http://name/ to http://machinename/ so, deploy again and we get error #2

2nd error: VSeWSS Service Error: Feature GUID is not installed in this farm, and can not be added to this scope. - when I figure this one out, I'll post an update.

All I have to say is what a POS!!!!! I gave up on trying to figure it out in VS. I went to Central Admin > Operations > Manage Solutions - the dumb solution is there so I deployed it. Then went to my site collection settings > Site Collection Features and activated the stupid web part.

After all that, a whole 4.5 hours later the web part is on a page and working. Next time just take a pencil and stab me in the eye.

SharePoint 2010 Migration Process

So hopefully you have done the research and prepared your 2007 for migration. Great! Lets get started.

A few things to note:

• 2010 CSS has totally changed, if you had 2007 custom branding cool, just need to take some extra time to work through it.
• 2010 large lists will error out, in your 2010 Central Administration set your Server Throttling options (this is a pretty rockin feature in my opinion, look for it in Exchange 2010 as well) this will allow your server to take a breather and catch up to handle requests.
• Custom code path changes from \12 to \14
• List views use XLS instead of CAML - cool right? I'm glad I spent all that time customizing lists with CAML.
• Remember JavaScript? Well...it's back! Bust out your books from 2000 and learn it.
• Recompile your custom code using the FeatureInstalled, Uninstalling, Activated and Deactivating methods.

Choose a Upgrade Path, what are your options?

• Inplace upgrade
• Build new 2010 farm and attach databases