Thursday, December 31, 2015

So obviously you are trying to follow the vast plethora of what i call an over-experienced deployable product - aka SharePoint Server.
As its deployment and administration best practices traveled through time with multiple puddle of sh#t situations to getting ourselves up and learning something new in every version, when it first started in 2003 with WSS 2.0 to a wonder of a product that is 2013 now.

One of the biggest lesson learnt all these years in my experience with multiple clients and deployment was missing out the importance of SQL aliases and the impact it has on migration and custom code in your farm.

So you are a good implementer and like a good implementer would do, you are configuring SQL Aliases for your instance (default or named) before u can run that "Configuration wizard" of yours and see your baby finally come to life. But like many road blocks in planning and designing phase, you get one more when your wizard fails and it turns out it cannot see your configuration database server.

there can be three permutation and combination of situation here.

1. Either your SQL Server management studio 2012 would fail with

2. Or your SharePoint Configuration wizard fails with:

3. Or both.

The core of the problem here is that SQL core database services, though being a 64-bit service. Its client aka Management studio is not, but your SharePoint 2013 is!!

So lesson learnt is to create both 32-bit and 64-bit aliases to avoid confusions

Sunday, April 18, 2010

Hi Folks,Back after a long time off blogging. Anyways, just a simple stupid thing I wanted to alert you with:Many times you may have 2 or 3 or even 4 AspMenu controls on your master page. This is usually the case in Publishing Internet facing portal, when you have links on top and bottom of master page other than the default Site level AspMenu navigation. Ones like these below, that will point to external sites out of our environment like www.myCompany.com or www.Mypartners.com

Well, nothing much, only that if you go with your default developer tendancy to copy paste the existing providers to create new ones will, kind of, make you scratch your head for a while as to why the links are not showing up. It took me 3 foolish hours to actually realise that, I'd had too much of vodka the night before to not see such a simple thing :All the existing SharePoint providers registered in web.config have securityTrimmingEnabled set to trueSo if you are copy pasting the existing providers and planning to simply change the required properties like providername or sitemap file, then keep this at back of your head to change this node, basically take this out or else, it will act upon the sharepoint's default role based membership and people and group membership and not let any of the external links render. For more Info in this, check out SiteMap Navigation Security.

Saturday, September 13, 2008

Suddenly, i see people so enthusiastic about "custom fields" that they want almost all kind of data retrieval through custom fields only!!..(You can read the comments on my custom fields post.)

From parent-child cascading drop-downs, to grandchild drop-down to why now even great great grand child drop-down??!!!. I am seeing people asking me to give solutions wherein i am sure they will end-up making half a dozen custom fields on one Item Edit page itself!!!

Some wants Custom data from a SQL store. Others from custom List lying in differnt Site Collection. Some even want data from Partners date in Oracle apps!! I Know, the idea of custom fields initially marvelled the new comers (which includes me too) and was even true in a specific real life case that i pointed out in my post. But custom fields are far more generic solutions that scopes to entire server deployment and I purely feel is not Intended to be used if there is only a particular List or library that demands this special type of data retrieval

My question here is, where have BDC gone?? WebParts are also brilliant solutions to many problems. Only that these guys should be used at right places.

Let say, so if you have a special data retrieval requirement wherein on first drop-down select, you want values in second drop down and on its select, in third and finally on its select. you want a group of 5 textboxes to be pre-populated. I feel, its not justice to WSS 3.0/MOSS if we are to conclude that this should be done through custom fields and thus demoralizing clients by quoting ,let say, 120$/Hr * 120 hrs = 1440$ of development time for nothing. Why the Hell they bought this ECM package that costed them lots of $s already.

Dont you think, webpart here would still be a better and more maintainable solution. The perfect recipe for such scenario would be "Custom Content Type + webpart on edit page"

This webpart can then have custom Oracle connection or SQL connection code to get that data in the wildest ways precievable. Or even, a better approach here would be using BDC object model to get data from thrid party stores or WSS object model to get it from other List of lists in different Site Collections.

Custom fields are good, but not at all a solution if your custom data retrieval logic restricts to only a particular List or Library. So guys, please dont end up making a latin american or indian family of custom field controls, every where!!, every time!!

(opinions expressed here are purely from my experience and have got nothing to do with microsoft SharePoint's best practices and guidelines. Please contact Andrew or Rob or other MVPs if there is a difference of opinion here)