Monday, August 20, 2012

SharePoint 2010 UPA Idle


DESCRIPTION

I ran into an issue with the User Profile Application (UPA) recently.  I had recently added a custom user property to the UPA and needed to do a full synchronization to pull in the values from Active Directory.  I manually initiated a full sync, however, the Profile Synchronization Settings remained "Idle."



SOLUTION


First thing I did was RDP to the SharePoint application server and to figure out the LOGONSERVER.  From the command line I typed:

echo %logonserver%

Doing this revealed that that the LOGONSERVER was a domain controller DC01.  I investigated to find that this server was running Windows Server 2003.  I continued to research the domain and found that the entire domain was running at 2003 level and there were a mix of 2003 and 2008 domain controllers.  The domain level wasn't the issue, but the specific server might be the issue.

Next, I manually changed the LOGONSERVER of the SharePoint  application server to a Windows Server 2008 domain controller named, DC03.  I did this from the command line using the following command:

set logonserver=\\DC03

With the LOGONSERVER updated, I attempted to run another full UPA sync.  It was successful this time.


Finally, I wanted to hard code this LOGONSERVER setting to ensure that I didn't have to monitor this.  To do this, I made the following change on the SharePoint application server:  Start, Control Panel, System, System Properties. Advanced Tab, Environment Variables, System Variables.  I added a System Variable called "LOGONSERVER" and I set it to DC03.

Sunday, August 19, 2012

Why Certain SharePoint Solutions Aren't The End Game

Generally speaking, as an organization matures, business processes often need to become more defined and standardized to facilitate repeatability and scalability.  Business processes may also  become more centralized out of necessity.  For example, if you have a lemonade stand on ten streets in town and each one is independently managed, the independent stands end up wasting a lot of time designing their own signs, figuring out how to process sales, and making trips to the grocery store.  If the lemonade stands centralize and standardize then perhaps there is only one group in charge of designing signs, and another group for stocking inventory, and another group for collecting the cash.  Each functional group can then serve the rest of the lemonade stands and the whole operation becomes much more efficient.


I believe that SharePoint has experienced a lot of success by helping companies get one step closer to the centralized and standardized model.  A sweet spot has been opportunities with ten independent lemonade stands.  I thing collaboration sites bridge a huge gap  at this stage when companies don't have mature processes in place, haven't figured out how to do things efficiently, and transactional systems are nowhere to be found.  Only after intentional progress and many waves of iteration will a company achieve great efficiency in such processes.  SharePoint helps in that progression...but I don't think that it is necessarily the end game in all cases.

One advantage to using SharePoint is it is quick and easy to get a solution up and running and the solution is probably a lot better than an email and document attachment process that was occurring before.  We can make successes in these situations and they are great steps forward.  If you read the Budgeting Portal Case Study you will see how SharePoint was used for Budgeting and Planning.  However, there comes a point where we need our process data to be completely integrated with other process data.  It needs to be relational.  It needs to be consistent.  And the ways we consume and produce the data electronically needs to be consistent and intuitive for us to achieve the level of efficiency that we are seeking.  Sometimes, our processes get to be too grown up for SharePoint, quite frankly.

The Budgeting Portal that I have been demonstrating at SharePoint Saturday events is only in SharePoint, temporarily.  Eventually, this is being moved to Hyperion Budgeting and Planning.  You see, a process that started off in email evolved to a document library in SharePoint.  Then it evolved again within SharePoint to include list data.  It continued to progress and get more sophisticated with custom databases, TSQL views and stored procedures, SSIS packages, SSRS reports, dashboards, and Data View Web Parts.  Then the practical limit within SharePoint was reached.  The data in the Budgeting Portal needed to be tied more closely to other financial data that could only be maintained in a financial system.  It became inevitable that this solution would need to become part of the overall financial system in order to facilitate the next wave of progression and efficiency.

Whether it is a lemonade stand or a budgeting and forecasting process, I believe that in many cases, we need to view SharePoint as a tool to help define a process, give it a place to become organized, mature it, and then transfer it to its permanent home.  I don't approach every project this way, but I am seeing this approach become more applicable and more common especially as transactional systems are becoming more flexible.  I believe that the core capabilities of ECM, collaboration, and social computing will eventually become very practical within CRM and ERP systems, which already provide business processes tuned for best practices and rigidity.  In the future, I believe that more and more SharePoint projects will be initiated, not with the purpose of being the end all, but rather with the purpose of promoting adoption of rigid processes in CRM and ERP.  SharePoint can help bridge the gap by being the interim solution where process discovery, definition, and initial improvements are made. 

SPS NYC: Case Study of a SharePoint 2010 Budgeting/Forecasting Portal


Event:
SharePoint Saturday New York City
Saturday, July 28, 2012

Session Title:
Case Study of a SharePoint 2010 Budgeting/Forecasting Portal

Abstract:
A professional services company required a company-wide budgeting solution in time to do year end budgeting, forecasting, and strategic planning.  The organization’s commercial off the shelf (COTS) finance system couldn’t fulfill the requirements.  Despite many resource and time constraints, a solution was developed and rolled out within 6 weeks using SharePoint Server 2010, a custom SQL Server database, SQL Server Integration Services (SSIS), SQL Server Reporting Services (SSRS), SharePoint Designer, and Data View Web Parts.  This session includes a demonstration of the solution as well as a walkthrough of the project approach and lessons learned.

Slides:

Case Study of a SharePoint 2010 Budgeting/Forecasting Portal.pdf