SharePoint 2010 RTM Still Requires SP_Farm to Run Profile Sync

Jan 10, 2013 9:36 PM, - Posted by Tommy Segoro

I normally install Sharepoint with the following configuration:

– Login using SP_Admin and install Sharepoint

– SP_Farm is used to run Farm service

In 2007 you can normally run Profile Sync with SP_Admin (account used to install Sharepoint) but in SP 2010 BETA this wasn’t the case. You have to logout and re-log back in using SP_Farm in order to run the Profile Sync manually.

I was actually expecting SP_Admin to be able to run Profile Sync since it’s a God-mode account but it wasn’t the case. I’ve tried to add it to Farm Administrators Group and yet I still couldn’t run it.

I’m not sure if this was done in purpose or just a left-over bug from BETA.

Cheers,

Tommy

SharePoint My Sites and Search Center, 404 Error Not Found

Jan 10, 2013 9:36 PM, - Posted by Tommy Segoro

When you’re configuring My Sites make sure you put in /Pages/ in the Search Center site settings otherwise it will return you with 404 Not Found error.

For example, if the Search Center site is set to http://moss2010:31000/ then you specify the following:

http://moss2010:31000/Pages/

If it’s set as a sub-site collection, eg http://testsite/sites/SearchCenter then you specify the following:

http://testsite/sites/SearchCenter/Pages/

Hope this helps,

Tommy

The Pitfalls of Sharepoint Projects – Part 3 – Everything Can Be Developed Using Sharepoint

Jan 10, 2013 9:36 PM, - Posted by Tommy Segoro

INTRODUCTION

This article is a series. The previous article can be found here Part 2.

Another pitfall that we may encounter is an expectation that Sharepoint can do everything. Well, can it do everything? IT CAN but with how much customisations?

First of all, it’s actually safe to say that Sharepoint is a custom application built on top of .NET framework in which you can pretty much build anything you want on top. However, Sharepoint has been developed and designed a specific way to serve a particular purpose so that it can perform its functions most efficiently.

Same with a mobile phone, I can use it to be a book marker, I can use it to hold my broken chair, I can use it to watch videos and browsing Facebook, etc. But it’s performing most efficiently if it’s used for calling and sending SMS.

Sharepoint is like that, too. You can always build custom feature receivers, page layouts, master pages, etc to achieve whatever you want, but it may take a lot of time to do. There may be other tools that can perform what you require a lot quicker and with minor modifications.

This has been a pitfall in Sharepoint engagement. Sure Sharepoint can automatically send flowers to someone you love on her birthday but you will need to develop custom lists, payment gateway processing, content types and fields, add-to-cart functionality, etc etc etc which an off-the-shelves shopping-cart application can just do straightaway.

HOW TO DEAL WITH THE SITUATION

So, what I can suggest is, do not just sell Sharepoint for the sake of it. But instead, find out what the client truly needs first and let Sharepoint be one of the technologies you can offer to achieve what’s required (does this make sense?).

If they need to provide online shopping capability then why use Sharepoint. They can simply deploy a simple and cheap shopping cart application and let Sharepoint be the point of collaboration (eg. viewing sales reports, etc).

Cheers,

Tommy

The Pitfalls of Sharepoint Projects – Part 2 – Approach Sharepoint Project by Phases

Jan 10, 2013 9:35 PM, - Posted by Tommy Segoro

INTRODUCTION

I was (and still am) discussing about the pitfalls that we may encounter during Sharepoint engagement. This is a series. The previous article can be found here Part 1.

I also realise that a lot of the times people tend to quote for the whole project so that the final full cost can be identified. This is not a bad practice except the number at the end can be very huge and scary.

Clients are clients. They will always say, “Just give us the final number mate. We understand that this is only a quote and may change depending on the requirements but just give us the final number so that we can prepare the budget for it.”. Then when we give back to them with $200K worth of development, I’m pretty sure that they’ll be scared off.

When this happens, PM/BDM/whoever deals with the client will start to cut things off (ie. time required to achieve a particular functionality) off just for the sake of winning the tender.

I’ve ever had a situation where we (the developers) quoted 1000 hours and it’s been cut-off to 300 hours. In the end, we ended up taking 1000 hrs anyway to finish off the task.

HOW TO DEAL WITH THE SITUATION

To deal with this particular scenario, always scope EVERYTHING (ie. every single piece of functionality) then break them down into phases. Prioritise the functionalities into the ones that need to be built first (ie. the must-haves) then to the least required.

Especially when writing quotes, client will appreciate this so much. They can start seeing what part of the requirements that take much time to develop. Trust me, a lot of the times they end-up de-prioritizing what’s been an important priority in the first place.

And by approaching it this way, client at least can start using the system sooner. They can at least play around with it just to find that the system is very helpful and making their work more efficient. Once they’ve been more familiar with it, they’ll start ask for more functionalities (hence more work for the server provider, hence more money and income).

Hope this helps,

Tommy

The Pitfalls of Sharepoint Projects – Part 1 – The Catch 22 “Design then plan or plan then design”

Jan 10, 2013 9:34 PM, - Posted by Tommy Segoro

INTRODUCTION

First of all, as part of this article: DOWNLOAD Business Requirements Document Template FOR FREE! We use it all the time to deliver SharePoint projects.

Hi everyone, in this particular opportunity I would like to share with you some of the pitfalls that we may encounter during our Sharepoint engagement. This is a series.

The very first part of this series is called The Catch 22 “Design then plan or plan then design”. A lot of the times I notice that clients want to see what Sharepoint can do first before implementing it fully which is fair enough. But how many times this happens that the “prototype” model suddenly becomes production version?

I give you an example:

One of my clients asked me about the greatness of Sharepoint. I obviously could explain to them. The meeting went about 1-2 hours and the agenda of the meeting was really to just going through Sharepoint features one-by-one, from My Sites, lists, document libraries, versioning, InfoPath, User Profile, etc etc etc.

At the end of the meeting the client came to me and said, “Mate, that looks awesome! I think it can help us a lot. However, before we fully implement it, we have to first find out whether the product can really help the other employees out and make the business more efficient or not. So, why don’t you create a prototype based on the requirements that I gave you, then we can go from there?”.

Well, here I was building the prototype. Several sites and sub-sites have been created with just OOTB look-and-feel, some content types and fields have also been developed. They’re all done through the UI because – let’s face it – it’s only a prototype!

The client then tried it out for few weeks and….. THEY LIKE IT!

I then came back to them and asked them to do a proper scoping and re-build the portal/Intranet (whatever you want to call it) properly. By this time client said to me, “Mate, we cannot lose content because people have been using it and they’ve uploaded documents, etc etc etc. If we have to re-build the portal from scratch and losing the content then we can’t have that.”.

So, in the end I had to work with the prototype and developed it from there which was a mess. Well, since it’s only a prototype to try out functionalities, the site structure wasn’t really thoroughly planned, the UI hasn’t been properly developed, the content types and fields (meta-data) haven’t really been thoroughly thought off, etc etc etc.

After all, the project costs client more money than if it’s rebuilt from scratch.

HOW TO DEAL WITH THE SITUATION

Some of the things I can share/suggest are:

– Keep reminding the client that it’s only a prototype and should not be used for day-to-day business use.

– Tell the client to not to work with the documents that are uploaded to it. They’re all purely for testing out functionalities such as versionins, etc.

– Give them timeframe to test out functionalities, eg. 2 weeks. If the client needs an extension then be it but at least we (the service provider) are being pro-active and following up the client.

– Never let the prototype to creep out and grow itself bigger than Ben Hur. Keep communicating with the client and ask them whether they’ve been more familiar with Sharepoint or not.

In any project, planning should always come first before designing. Therefore, without a proper planning, Sharepoint projects can cost a lot of money. I shouldn’t say that it (SP project) will fail but at least it will cost a lot more money than if it’s properly planned.