A visual aid from #SP24 conference on SP Cloud vs OnPrem
Showing posts with label Architecture. Show all posts
Showing posts with label Architecture. Show all posts
Monday, April 21, 2014
#SP24 : SP Solutions vs Apss
A quick visual aid from one of the speaker in #SP24.
How do you choose between SP Solutions and SP Apps?
How do you choose between SP Solutions and SP Apps?
#SP24 : How good is SP2013 as a WCM?
I have never worked with other Web Content Management (WCM) system other than SharePoint. So, I am wondering how good is it? And what alternatives do we have?
And here are few slides to broaden awareness what platform do we have and where SharePoint has his place.
And here are few slides to broaden awareness what platform do we have and where SharePoint has his place.
#SP24 : Mobile Strategy by Joel Oleson. Go responsive!
+Joel Oleson in #SP24S112 talked about Mobile strategy and design. Go mobile, social and cloud!
82% online population engages in social networking,
50% on enterprise customers are "on the road" to cloud.
People spend more time on mobile apps (89%) than on mobile web (11%)
Most Weekday Tablet usage is between 8PM and 9PM
Few slide to illustrate the point:
The leading sales in the smartphone market is Android
And here is a reality check in SharePoint 2013
92% companies don't support Mobile Access to SharePoint
In SharePoint 2013 you have a contemporary view for HTML5 aware devices. Joel insists that we need to more than contemporary view.
Side note: Project Server web access doesn't support contemporary view. Publishing sites are not suitable for this type of view. The contemporary view main intend is to show the folders and files, not a publishing pages and business process applications.
O365 mobile apps:
Joel' key takeaways and considerations:
Resoures:
http://responsivesharepoint.codeplex.com/
82% online population engages in social networking,
50% on enterprise customers are "on the road" to cloud.
People spend more time on mobile apps (89%) than on mobile web (11%)
Most Weekday Tablet usage is between 8PM and 9PM
Few slide to illustrate the point:
92% companies don't support Mobile Access to SharePoint
In SharePoint 2013 you have a contemporary view for HTML5 aware devices. Joel insists that we need to more than contemporary view.
Side note: Project Server web access doesn't support contemporary view. Publishing sites are not suitable for this type of view. The contemporary view main intend is to show the folders and files, not a publishing pages and business process applications.
O365 mobile apps:
- SP 2013 Native Mobile browsing has improved for all mobile platform;
- New SP Mobile Apps can make accessing social +people+document easier
- Consider 3d party mobile apps to fill gaps like Offline Sync, Search, Security and Mobile Device App mgmt
- Plan for Mobile Intranets: Seriously consider Industry Best Practices of Responsive Web design
Resoures:
http://responsivesharepoint.codeplex.com/
#SP24 : Search strategy
Jeff Fried presented #SP24S034 the successful Search Strategy. People first.
Key other takeaways:
The common traps in search architecture
Trap #1. "Trying to build a google"
It's a wrong goal because:
- Google has a huge support to keep it running
- Google goal is different than enterprise goal of the company.
The enterprise search goal is business process centric.
Trap #2. "One Search Center for everything"
Search should be business process specific
Ex. Online shopping, dinner, apartment rent
Trap #3. "Stand up OOB search and walk away"
Search needs maintenance
Trap #4. "The technology first"
Even though indexes are crucial for search, need to remember that people create meaning out of the indexes.
So we need to know people first - what and how they search
So we need to know people first - what and how they search
Jeff introduced a concept of Information Strategy that ties together:
- Information Governance;
- Information Architecture;
- Information Security;
- Information Intelligence.
Meantime, the Search Strategy is a 3 part interdependent system:
And here are the keys of the success in Search Strategy:
Context – users need to find different info depending on
their role, needs, tasks.
Hence the notion of having one place to find everything is not efficient.
Friday, March 28, 2014
Managed metadata: 5 things that you wish you knew before using term store management tool in SharePoint
My recent posts are more on the darker side. I see the mistakes, issues and flaws in SharePoint, as well as in working with SharePoint.
It doesn't mean that SharePoint is getting worse, it just means I am getting better). I know more, I see more.
Last couple of years, I was working on understanding how to use SharePoint right. Where SharePoint is helpful, what feature is more appropriate for the specific use case.
Finally, I have figured out where Managed metadata can bring value.
More on that:
I have implemented managed metadata, and have used it successfully to improve findability in the portal.
Nevertheless, working with managed metadata in the real world portal highlights some flaws that currently exist in Term Store management implementation.
1. No history, no
versioning
There is no way to see changes made in the term store, nor you can't revert changes.
2.No author of the
term
The term doesn't have an author field. So, there is now way to know who created or modified and when the term.
3. No usage (where
value is used)
Being in the term store you can't trace where the term has been used.
4. No UI to backup\restore
What you can do is to reach out for PowerShell to export term to backup it.
5. No sync options in case of Hybrid Cloud Architecture
There is no way to maintain term store in sync between 2 farms: on-prem and SharePoint Online
These 5 things can be easily significant in the large implementation of the SharePoint. I hope that you know them before making decision. And it doesn't mean that these facts stop you, but you will be better equipped to set the expectations right.
Common mistakes in SharePoint 2013 Arhitecture
I am participating in the upgrade from SharePoint 2007 to SharePoint 2013 on premises. It is nice to be back in upgrade work since it was my main activity last 6 years). This time it's a little bit different.
First of all, the upgrade is from SharePoint 2007 to SharePoint 2013. We do it through a transitional SharePoint 2010 farm.
And second of all, I wasn't involved in the architecture phase of building the farm. I jumped on the upgrade bandwagon just before the final prod upgrade. So, what I do mainly is verifying that new farm is in the working conditions and testing once again the content migration.
Along the way I see how people built the farm and streamlined the upgrade process. It's a good experience to have to observe different style of working with SharePoint. I am free of making architectural decisions, but at the same time I am experienced enough to see outcome of decisions that were made by others.
This post is about my observations on common SharePoint 2013 architectural mistakes.
I can get "editing in the browser" feature with no additional configuration
No, you have to have 2 conditions to have Office Web Apps on the farm:
1. Office Web App server
2. Claim based web application
You need to have OWA server. You can't place OWA on App server. It should be a dedicated server for Office Web App server.Plan for an additional server in the farm.
Office Web Apps can be used only by SharePoint 2013 web applications that use claims-based authentication
OWA server will handle all Excel calculation
First of all, the upgrade is from SharePoint 2007 to SharePoint 2013. We do it through a transitional SharePoint 2010 farm.
And second of all, I wasn't involved in the architecture phase of building the farm. I jumped on the upgrade bandwagon just before the final prod upgrade. So, what I do mainly is verifying that new farm is in the working conditions and testing once again the content migration.
Along the way I see how people built the farm and streamlined the upgrade process. It's a good experience to have to observe different style of working with SharePoint. I am free of making architectural decisions, but at the same time I am experienced enough to see outcome of decisions that were made by others.
This post is about my observations on common SharePoint 2013 architectural mistakes.
No, you have to have 2 conditions to have Office Web Apps on the farm:
1. Office Web App server
2. Claim based web application
You need to have OWA server. You can't place OWA on App server. It should be a dedicated server for Office Web App server.Plan for an additional server in the farm.
Office Web Apps can be used only by SharePoint 2013 web applications that use claims-based authentication
Office Web Apps Server enables you to view workbooks that
contain Data Models that use native data. However, you can’t explore data in
items such as PivotTable reports, PivotChart reports, and timeline controls
that use a Data Model as the data source.
Excel Web App runs in one of two
modes:
SharePoint view mode In
this mode, Excel Services is used to view workbooks in the browser.
Office Web Apps Server
view mode In this mode, Excel Web App is used
to view workbooks in the browser.
Excel Services, and Excel Web App all have a lot in common, but they are not exactly the same. These applications can differ in what workbook features are supported for viewing in a browser
More on SharePoint 2013 architectural pain points
More on SharePoint 2013 architectural pain points
SP farm doesn't use SQL alias
An old and common mistake. I have just recently jumped on the project after the farm was already configured. The first thing that makes me sick in the farm, that there is no alias for SQL.
So, in case you sql server dies and need to make sure that you name the new server the same way as previous one.
Wednesday, March 26, 2014
User Profile Service: View the management agent run history for details.
Do you still use FIM for User Profiles in SharePoint 2013?
If requirements allow, I highly recommend to switch to SharePoint Active Directory Import
If not, you may be lost with intricacy of FIM configuration. I hope this How to start User Profile Synchronization service post alleviate some configuration pain.
One the Sp2013 uses FIM, and I recently found an error message in the event log:
The management agent "MOSSAD-User Profile Synchronisation" failed on run profile "DS_FULLIMPORT" because of connectivity issues.
Additional Information
Discovery Errors : "0"
Synchronization Errors : "0"
Metaverse Retry Errors : "0"
Export Errors : "0"
Warnings : "0"
User Action
View the management agent run history for details.
And was wondering where IS this agent run history.
Here it is:
C:\Program Files\Microsoft Office Servers\15.0\Synchronization Service\UIShell
If requirements allow, I highly recommend to switch to SharePoint Active Directory Import
If not, you may be lost with intricacy of FIM configuration. I hope this How to start User Profile Synchronization service post alleviate some configuration pain.
One the Sp2013 uses FIM, and I recently found an error message in the event log:
The management agent "MOSSAD-User Profile Synchronisation" failed on run profile "DS_FULLIMPORT" because of connectivity issues.
Additional Information
Discovery Errors : "0"
Synchronization Errors : "0"
Metaverse Retry Errors : "0"
Export Errors : "0"
Warnings : "0"
User Action
View the management agent run history for details.
And was wondering where IS this agent run history.
Here it is:
C:\Program Files\Microsoft Office Servers\15.0\Synchronization Service\UIShell
Wednesday, February 19, 2014
SharePoint Architecture: Role of Enterprise Taxonomy in IA
The single most important task of a SharePoint is to find information.
There are 2 main strategies to achieve this:
In SharePoint world there is a combination of two these strategies that in the end gives rise to Information Architecture.
To put it simply, SharePoint Information Architecture is:
1. Sites and libraries organization and structure;
2. As well as, metadata and managed metadata.
Since SharePoint 2010 SharePoint Information Architecture got richer, thanks to a new feature – Enterprise Taxonomy.
Corporate taxonomy is the hierarchical classification of entities of interest of an enterprise, organization or administration, used to classify documents, digital assets and other information.
Right implementation of Enterprise Taxonomy provides common language within the company, across departments.
Mutual agreement on the meaning of words in Enterprise dictionary simplifies the process of:
1. Information tagging
2. Information retrieving
As you can see, Enterprise taxonomy plays crucial role in finding information in portal.
I hope this bird eye overview helps you to identify business problem areas that can benefit from Enterprise Taxonomy implementation.
Read more on Taxonomy ideas and technical challenges
There are 2 main strategies to achieve this:
1. Train people look for information in one particular spot.
Like in a real world, in the grocery market, you want to find an apple, you go to Fresh Produce aisle.
2. Make information searchable the way the people usually search such kind of information.
Like in Internet, whenever you have got a question, you just google it. You don’t need to know where the information is stored, as long as you remember how to reach a search engine, and as long the data is searchable.
Like in a real world, in the grocery market, you want to find an apple, you go to Fresh Produce aisle.
2. Make information searchable the way the people usually search such kind of information.
Like in Internet, whenever you have got a question, you just google it. You don’t need to know where the information is stored, as long as you remember how to reach a search engine, and as long the data is searchable.
In SharePoint world there is a combination of two these strategies that in the end gives rise to Information Architecture.
To put it simply, SharePoint Information Architecture is:
1. Sites and libraries organization and structure;
2. As well as, metadata and managed metadata.
Since SharePoint 2010 SharePoint Information Architecture got richer, thanks to a new feature – Enterprise Taxonomy.
Corporate taxonomy is the hierarchical classification of entities of interest of an enterprise, organization or administration, used to classify documents, digital assets and other information.
Right implementation of Enterprise Taxonomy provides common language within the company, across departments.
Mutual agreement on the meaning of words in Enterprise dictionary simplifies the process of:
1. Information tagging
2. Information retrieving
As you can see, Enterprise taxonomy plays crucial role in finding information in portal.
I hope this bird eye overview helps you to identify business problem areas that can benefit from Enterprise Taxonomy implementation.
Read more on Taxonomy ideas and technical challenges
Thursday, October 3, 2013
SharePoint: Search analytics or How to Improve Search
Recently, I have been diving deeper into Information Architecture
Key Issues in Governance Planning is Search
Google search and sharepoint search shouldn't work the same
when you google something you will get a lots of something
when you search in SharePoint, your intention get less but more relevant information to make business decision quicker. You are confined in bussiness jargon you use in your organization, or by author you are searching for.
Typical Search problems:
- Garbage in, Garbage out
- Poort meta data
- Too much noise
- Irrelevant content on top
- Useless content
- Duplicate content
- Bad document authoring (pdf, MSOffice)
- Misalligment with/misunderstanding users' conceptions
- No Improvement over time
Actions to improve search:
- Use Site Collection Web Reports
- Check statistics weekly in the first 3 months
- Make 20-50 Best Bets
- Check monthly and adjust
- Improve titles descriptions
- Add metadata
- Map existing metadata
How to use Site Collection Web Reports to analyze Search?
How do you know of search needs improvement?
Start with "Failed Queries" /_layouts/WebAnalytics/Report.aspx?t=SearchFailureReport&l=sc
Look at the numbers of Queries that are failed. Compare with numbers of visitors
If you see that failed numbers are high, this is the first indication that you have to improve search.
Percentage abandoned value indication:
returned no results - need to see if we can improve content exposure (via metadata) to show the result based on criteria
100% - users didn't follow any link that been shown in the result page. Check the result by yourself, analyze why content is not used by user. Is it wrong metata that describes the content or user uses different terminology?
How do you analyze UX via Search?
If visitor numbers are high /_layouts/WebAnalytics/Report.aspx?t=UniqueVisitorsTrend&l=sc
, but rarely people use Search overall _layouts/WebAnalytics/Report.aspx?t=SearchTrafficTrendReport&l=sc
, it might mean that you navigation is great
or users go only to the specific places without exploration what else can be useful in the portal and maybe you need to promote search feature more.
If users intensely use search it might indicate that you have to improve your navigation page
How can you reduce failed queries?
Add a search keyword with best bet.
Best Bet is a promoted result. Analyze use of the Best Bets via "Best Bets usage" - _layouts/WebAnalytics/Report.aspx?t=BestBetPerformanceReport&l=sc
This note is based on Search Analytics in SharePoint 2010
Key Issues in Governance Planning is Search
Google search and sharepoint search shouldn't work the same
when you google something you will get a lots of something
when you search in SharePoint, your intention get less but more relevant information to make business decision quicker. You are confined in bussiness jargon you use in your organization, or by author you are searching for.
Typical Search problems:
- Garbage in, Garbage out
- Poort meta data
- Too much noise
- Irrelevant content on top
- Useless content
- Duplicate content
- Bad document authoring (pdf, MSOffice)
- Misalligment with/misunderstanding users' conceptions
- No Improvement over time
Actions to improve search:
- Use Site Collection Web Reports
- Check statistics weekly in the first 3 months
- Make 20-50 Best Bets
- Check monthly and adjust
- Improve titles descriptions
- Add metadata
- Map existing metadata
How to use Site Collection Web Reports to analyze Search?
How do you know of search needs improvement?
Start with "Failed Queries" /_layouts/WebAnalytics/Report.aspx?t=SearchFailureReport&l=sc
Look at the numbers of Queries that are failed. Compare with numbers of visitors
If you see that failed numbers are high, this is the first indication that you have to improve search.
Percentage abandoned value indication:
returned no results - need to see if we can improve content exposure (via metadata) to show the result based on criteria
100% - users didn't follow any link that been shown in the result page. Check the result by yourself, analyze why content is not used by user. Is it wrong metata that describes the content or user uses different terminology?
How do you analyze UX via Search?
If visitor numbers are high /_layouts/WebAnalytics/Report.aspx?t=UniqueVisitorsTrend&l=sc
, but rarely people use Search overall _layouts/WebAnalytics/Report.aspx?t=SearchTrafficTrendReport&l=sc
, it might mean that you navigation is great
or users go only to the specific places without exploration what else can be useful in the portal and maybe you need to promote search feature more.
If users intensely use search it might indicate that you have to improve your navigation page
How can you reduce failed queries?
Add a search keyword with best bet.
Best Bet is a promoted result. Analyze use of the Best Bets via "Best Bets usage" - _layouts/WebAnalytics/Report.aspx?t=BestBetPerformanceReport&l=sc
This note is based on Search Analytics in SharePoint 2010
SharePoint 2013: Architectural changes. Pain Points
As I have launched a migration project to SharePoint 2013, I have started analyzing the architectural changes in SharePoint 2013 farm and other related products.
My goal is to migrate SharePoint 2010 with Project Server 2010 to SharePoint 2013 with Project Server 2013.
Here is my earliest discoveries:
1. Hardware recommendations differ for SharePoint 2013 and for Project Server 2013. But Project Server lives inside the SP Farm.
For small SP farm, you have to have around 12 Gb for Front End and 8 Gb for SQL.
But in case you want to include Project Server in the farm, MS recommends 16Gb for Front End and 16 Gb for Sql.
NOTE: This 16 Gb recommendation doesn't cover additional need for memory by other SP services:
At this moment, I am struggling to find on-prem VMs for a new demanding farm. Realistically, I will not get more than 10 GB RAM for SP+Project Server 2013.
PAINT POINT: You have to boost hardware not only for SP2013 ,but for Project Sever 2013 accommodation.
2.Office Web Apps server (or OWA farm) should be installed on dedicated server (NOT ON THE SP SERVER).
And by the way, have you acquainted with PowerShell? OWA Sever doesn't have UI to set settings, you have to use PowerShell 3.0.
Once you have installed OWA farm (server) , you have to bind (SPWopiBinding) SP to it.
Now, think twice in case of migration.
Not only you have to boost hardware for serves, you have to find an additional server in order to have Office Web Apps. In SP2010 Office Web Apps product was supposed to be installed on the SP server.
PAINT POINT: You have to find an additional server for OWA to provide functionality that was "hardware-strain" free in the previous SP version.
3. Web analytics services are removed from Sp2013 as a separate services. Now it's a part of Search Service.
4. A new Access Service requires SQL 2012.
In case you want\or have to provide Access Service in your SP 2013 Farm, you have point the service to SQL 2012 Server.
PAINT POINT: For Access Service you have to have SQL 2012. So if you have planned to stick with SQL 2008, make sure you don't need to have Access Service. In case you need it you have 2 choices: 1. Have 2012 SQL server installed at the first place, or 2. extend you farm and include additional 2012 SQL server to accommodate Access Service Application.
My goal is to migrate SharePoint 2010 with Project Server 2010 to SharePoint 2013 with Project Server 2013.
Here is my earliest discoveries:
1. Hardware recommendations differ for SharePoint 2013 and for Project Server 2013. But Project Server lives inside the SP Farm.
For small SP farm, you have to have around 12 Gb for Front End and 8 Gb for SQL.
But in case you want to include Project Server in the farm, MS recommends 16Gb for Front End and 16 Gb for Sql.
NOTE: This 16 Gb recommendation doesn't cover additional need for memory by other SP services:
The minimum hardware requirements in this section are recommended in which only the required services to run Project Server 2013 are enabled. Be aware that enabling additional SharePoint Server 2013 features in the farm may require more resources.So, it seems like MS intends to sale lots of Azure VM services!
At this moment, I am struggling to find on-prem VMs for a new demanding farm. Realistically, I will not get more than 10 GB RAM for SP+Project Server 2013.
PAINT POINT: You have to boost hardware not only for SP2013 ,but for Project Sever 2013 accommodation.
2.Office Web Apps server (or OWA farm) should be installed on dedicated server (NOT ON THE SP SERVER).
And by the way, have you acquainted with PowerShell? OWA Sever doesn't have UI to set settings, you have to use PowerShell 3.0.
Once you have installed OWA farm (server) , you have to bind (SPWopiBinding) SP to it.
Now, think twice in case of migration.
Not only you have to boost hardware for serves, you have to find an additional server in order to have Office Web Apps. In SP2010 Office Web Apps product was supposed to be installed on the SP server.
PAINT POINT: You have to find an additional server for OWA to provide functionality that was "hardware-strain" free in the previous SP version.
3. Web analytics services are removed from Sp2013 as a separate services. Now it's a part of Search Service.
When you upgrade to SharePoint 2013, do not attach and upgrade the databases that contain the data from Web Analytics in SharePoint Server 2010. We recommend that you turn off Web Analytics in the SharePoint Server 2010 environment before you copy the content databases that you want to upgrade to SharePoint 2013.PAINT POINT: Web analytics are best service to clean your farm before you go to SharePoint 2013. It allows you find unused spwebs. But you have to turn the service off when you want to copy your content db for test upgrade. So, you need to clean the environment (with help of Web analytics) before even your first test upgrade.
4. A new Access Service requires SQL 2012.
In case you want\or have to provide Access Service in your SP 2013 Farm, you have point the service to SQL 2012 Server.
PAINT POINT: For Access Service you have to have SQL 2012. So if you have planned to stick with SQL 2008, make sure you don't need to have Access Service. In case you need it you have 2 choices: 1. Have 2012 SQL server installed at the first place, or 2. extend you farm and include additional 2012 SQL server to accommodate Access Service Application.
Friday, May 24, 2013
Is SharePoint rubbish? Trash talk on SharePoint architecture
I have recently bought a book by one of the favorite knowledgeable guy in the SharePoint world - Todd Klindt - Professional SharePoint 2013 Administration
The book is hilarious and very descent to have on the shelf if you are a SharePoint Administrator, Developer or Architect.
Here is my favorite paragraph so far, which is very metaphorical and easy memorize for someone who is new in this big and messy SharePoint World.
"Try this analogy to understand how [all] pieces work together: Web applications are the landfill. Content databases are giant dumpsters. A site collection is a big, black 50-gallon garbage bag. Webs, lists, and items are pieces of trash. Your users spend all week creating garbage, continuously stuffing it in the garbage bags, with each piece of trash occupying only one garbage bag at a time. Each garbage bag can hold only 50 gallons of trash (quotas) before it is full, after which the user has to either ask for a new garbage bag or get a bigger garbage bag. That full garbage bag is placed in a dumpster, and it is not possible to put a garbage bag in more than one dumpster without destroying it. Dumpsters are serviced only by one landfill but that landfill can handle thousands of dumpsters without issue. "
Friday, March 22, 2013
SharePoint 2010 on Cloud. SaaS vs IaaS
Ever wonder how can you move your on-prem SP farm to the cloud? And what is cloud anyway?
As of 03/22/2013 you have 2 options of cloud-solution for SharePoint:
- Office 365 that deliver bunch of MS products , one of them is SharePoint Online.
This is a classical example of SaaS.
- WIndows Azure VM.
This is a classical example of IaaS.
Here is a good pic to describe SaaS (Software as a Service), PaaS (Platform as a Service) and IaaS (Infrastructure as a Service):
In the context of SharePoint migration to the cloud, you need to understand that SharePoint Online delivers the latest version of SharePoint
What is the implication? You have to be totally ready to move SP2013 .MS doesn't offer a mean to move data from your on-prem to SharePoint online.
At this moment I haven't tried any 3d party tools for this purpose yet.
Also, your farm should not have farm solutions. SharePoint Online doesn't support farm solutions. And it doesn't support reporting services at this moment.
Windows Azure VM gives you more flexibility. You can choose what version of SharePoint you want to run, and you have a full control to administer the system. More on SharePoint Deployment on Windows Azure Virtual Machines
But also it means you have to have a resource to support the system.
And by the way, wonder how can you cut the cost? I wonder too)
At this moment, it's interesting to know that:
As of 03/22/2013 you have 2 options of cloud-solution for SharePoint:
- Office 365 that deliver bunch of MS products , one of them is SharePoint Online.
This is a classical example of SaaS.
- WIndows Azure VM.
This is a classical example of IaaS.
Here is a good pic to describe SaaS (Software as a Service), PaaS (Platform as a Service) and IaaS (Infrastructure as a Service):
In the context of SharePoint migration to the cloud, you need to understand that SharePoint Online delivers the latest version of SharePoint
What is the implication? You have to be totally ready to move SP2013 .MS doesn't offer a mean to move data from your on-prem to SharePoint online.
At this moment I haven't tried any 3d party tools for this purpose yet.
Also, your farm should not have farm solutions. SharePoint Online doesn't support farm solutions. And it doesn't support reporting services at this moment.
Windows Azure VM gives you more flexibility. You can choose what version of SharePoint you want to run, and you have a full control to administer the system. More on SharePoint Deployment on Windows Azure Virtual Machines
But also it means you have to have a resource to support the system.
And by the way, wonder how can you cut the cost? I wonder too)
At this moment, it's interesting to know that:
Virtual machines continue to incur compute charges even when they are stopped You can avoid these charges by deleting the virtual machine.BTW, in case you want to automate SP installation process, try this - http://autospinstaller.codeplex.com/
Monday, February 11, 2013
Simple concept: Property bag VS Hierarchical Object Store
[Question]: Ever wondered what the difference between Property bag and Hierarchical Object Store in SharePoint?
[Answer]: A nice and short (that how I like) article on that here - Where Should You Store Your SharePoint Solution’s Configuration Data?
The big discovery for me was that:
Property bag is store in the content database;
Hierarchical Object Store in the config database.
More on Managing Custom Configuration Options for a SharePoint Application
[Answer]: A nice and short (that how I like) article on that here - Where Should You Store Your SharePoint Solution’s Configuration Data?
The big discovery for me was that:
Property bag is store in the content database;
Hierarchical Object Store in the config database.
More on Managing Custom Configuration Options for a SharePoint Application
Thursday, October 11, 2012
SharePoint Limits
This is a very short post on SharePoint limitations.
Here is few links that will help at least me to reach this info easily:
Software boundaries and limits for SharePoint Server 2013
SharePoint Online: software boundaries and limits (SP 2010 Online. At the moment of creation of this post we still have SP2013 in Preview)
SharePoint Server 2010 capacity management: Software boundaries and limits
Plan for software boundaries (Office SharePoint Server 2007) , and a short version of SharePoint 2007 Limits
And my old posts on:
Large list limits Sharepoint 2007/2010
"Column Limit Exceeded" Message When You Add a New Column to a SharePoint Services List
Happy analyzing to you!
Often when you negotiate software requirements for SharePoint project, you need to have at hand information what SharePoint cant' do and what it can (especially - Boundaries: Static limits that cannot be exceeded by design)
Here is few links that will help at least me to reach this info easily:
Software boundaries and limits for SharePoint Server 2013
SharePoint Online: software boundaries and limits (SP 2010 Online. At the moment of creation of this post we still have SP2013 in Preview)
SharePoint Server 2010 capacity management: Software boundaries and limits
Plan for software boundaries (Office SharePoint Server 2007) , and a short version of SharePoint 2007 Limits
And my old posts on:
Large list limits Sharepoint 2007/2010
"Column Limit Exceeded" Message When You Add a New Column to a SharePoint Services List
Happy analyzing to you!
Thursday, September 13, 2012
SharePoint sandboxed solutions are deprecated in SharePoint 2013
Yesterday, a new SharePoint developer was frustrated with limitations in Sandbox solution that he has to develop for SharePoint Online, which at this moment (September 2012) is on SharePoint 2010.
He send me an email with a link to Apps for SharePoint compared with SharePoint solutions and a glorious title SharePoint sandboxed solutions are deprecated in SharePoint 2013 Preview
It's totally understandable when you are trying to find a way to get rid of , as I call it, SharePoint development madness.
Let me explain myself. For me, SharePoint development madness feels like an internal feeling of frustration and hopelessness. It is rooted in deep sense of overwhelming.
You as a new SharePoint developer is constantly have an impression that you have to know a lot beforehand in order to write a first line of code for SharePoint.
And I were there... not a nice place. SharePoint community calls it -a steep learning curve...
I have posted recently a quick note on where to start in SharePoint development for a newbie. It might help initially to catch some fundamentals.
If your case is that you have to develop something in sandbox for SharePoint 2010, but you have already heard a lot about SharePoint 2013 new development Apps you almost certainly feel left behind.
You feel cheated since MSDN says that Sandboxed solutions are deprecated in SP2013 Preview? Be hold!
Here is me perspective on this emotional issue:
He send me an email with a link to Apps for SharePoint compared with SharePoint solutions and a glorious title SharePoint sandboxed solutions are deprecated in SharePoint 2013 Preview
It's totally understandable when you are trying to find a way to get rid of , as I call it, SharePoint development madness.
You as a new SharePoint developer is constantly have an impression that you have to know a lot beforehand in order to write a first line of code for SharePoint.
And I were there... not a nice place. SharePoint community calls it -a steep learning curve...
I have posted recently a quick note on where to start in SharePoint development for a newbie. It might help initially to catch some fundamentals.
If your case is that you have to develop something in sandbox for SharePoint 2010, but you have already heard a lot about SharePoint 2013 new development Apps you almost certainly feel left behind.
You feel cheated since MSDN says that Sandboxed solutions are deprecated in SP2013 Preview? Be hold!
Here is me perspective on this emotional issue:
As it says in Apps for SharePoint compared with SharePoint solutions SharePoint sandboxed solutions are deprecated in SharePoint
2013 Preview in favor of developing apps for SharePoint, but sandboxed
solutions can still be installed to site collections on SharePoint 2013
Preview.
My impression that MS believes
that APP can replace all functionality that is possible to implement in sandbox
solution. But at the same time, we don’t know what’s going to be a new
hit in the version after SP2013.
MS doesn’t announce the release date for Sp2013. Some rumors say it might launch 1Q of 2013.
If you feel uncomfortable
to develop server side code in Sandbox solution, the only option I can see is
Client-Side development: Client-Side Access and Remote Access
I believe you can develop
client-side logic (javascript) and deploy it via Sandbox solution.
To summarize, we have to stick
with sandbox since we don’t have any other option at this moment. But you still
have a freedom to choose how you will implement the logic (server side\client
side).
Once we are over the hill and
with SP2013, I would glad to see you moving logic out of the sandbox to APP if this is appropriate.
Business doesn't jump fast to a
new version. I predict that we will have more clients with SP2010 in the next
few years rather than with SP2013.
For more information on SandBox vs APPs in 2013:
Monday, June 25, 2012
SharePoint: High Availability
Recently, I have been asked to develop a plan to make SharePoint 2010 farm Highly Available.
This short post will outline the main phases that farm needs to undergo in order to be Highly Available.
In my case, we have 2 datacenters. One of them is Primary, and another - Secondary. In case primary goes down, we should provide a seamless switch to the Secondary without loss functionality and preferably performance.
In my personal opinion, I prefer to give performance boost in case I have resources, even it might mean that end-users will notice some performance degradation in case of failover.
Here is a schema to implement for High Availability:
Here are key notes:
1. Web Front Ends (WFEs) - When Primary is up, all 4 WFEs (primary and secondary) are serving the requests. In case the Primary is out, the Secondary WFEs will be getting all requests.
Here I see, that it may impact performance, since in the usual scenario end-users uses all 4 WFE (that load-balanced via ISA).
One of the option to keep WFE performance steady, is to keep only 2 WFEs available in case Primary is up.
The seamless switch will be provided via ISA
2. SharePoint application server - both of them engaged in case Primary is up. In case of failover, the second application server should have the same services running as in Primary to maintain the same functionality as before.
The weakest point is a timer job. I can imagine that in some scenarios WFs that been served by primary server at the time of failover will never get back.
One more note on this- plan your search architecture: Search Service Application: Architecture in one page
3. SSRS servers - in case Primary is active, engage both. In case of failover the second SSRS will get all requests. The seamless switch will be provided via ISA
4. Often enterprise SharePoint solution interact with external system via BDC (Trying to figure out what's the difference between 2007 BDC and 2010 BCS?)
We need to plan how we can provide access to these external system in case of failover.
That means extensive communication with teams who support such system.
In my example, we accumulate all external systems calls via web services developed on BizTalk server. From our side, we need to configure ISA to have additional BizTalk availabled on the Secondary datacenter.
5.On SQL side - we are implementing async mirroring. In case primary goes down, we don't have any loss and ready to switch to the Secondary.
I prefer to have a witness on the Secondary based on assumption that we use Secondary in case Primary is down, not vice versa.
In case report db servers fail in the Primary, we need to have extra work from front-ent side. Report connection files have connection information inside them. We need to make sure that all connection files have alias name instead of the actual. In the case of failover, we just modifing alias on Report server side. Keep in the mind that SSAS type of connection file won't work with SQL alias and we can do it via host file.
We need to setup failover settings for SharePoint databases.
Refer to this post for what can be mirrored in SharePoint 2010:
The 2010 SharePoint databases, purposes and mirroring supportability
You will find that some of the SharePoint DBs are not required and are not design to setup for failover since they are not critical and easy to re-create.
Based on what recover time you have , adjust for yourself what needs to be configured with failover and what can be omitted. If a SharePoint db is not configured with failover, plan ahead what necessarily actions you should pefrom to put the bd back in case of failure, and what impact will be if the db is not ready right away. As an example, most likely the StateService will not be in high demand right after switching to the reserved (Secondary) datacenter.
Here is an outline plan how to introduce HA in SharePoint 2010 farm gradually:
1. Decide how many additional servers are needed, and their configuration.
2. WFE. Test first without including in ISA. Then include in the prod farm.
3. App server. Build the server cautiously. I believe once the app server is joined, it will used by prod WFE. No ISA configuration is needed. All requests goes from the SharePoint farm configuration directly.
4. Work on external systems HA
5. Work on SQL servers, failover settings on SharePoint side
6. SSRS servers
This short post will outline the main phases that farm needs to undergo in order to be Highly Available.
In my case, we have 2 datacenters. One of them is Primary, and another - Secondary. In case primary goes down, we should provide a seamless switch to the Secondary without loss functionality and preferably performance.
In my personal opinion, I prefer to give performance boost in case I have resources, even it might mean that end-users will notice some performance degradation in case of failover.
Here is a schema to implement for High Availability:
Here are key notes:
1. Web Front Ends (WFEs) - When Primary is up, all 4 WFEs (primary and secondary) are serving the requests. In case the Primary is out, the Secondary WFEs will be getting all requests.
Here I see, that it may impact performance, since in the usual scenario end-users uses all 4 WFE (that load-balanced via ISA).
One of the option to keep WFE performance steady, is to keep only 2 WFEs available in case Primary is up.
The seamless switch will be provided via ISA
2. SharePoint application server - both of them engaged in case Primary is up. In case of failover, the second application server should have the same services running as in Primary to maintain the same functionality as before.
The weakest point is a timer job. I can imagine that in some scenarios WFs that been served by primary server at the time of failover will never get back.
One more note on this- plan your search architecture: Search Service Application: Architecture in one page
3. SSRS servers - in case Primary is active, engage both. In case of failover the second SSRS will get all requests. The seamless switch will be provided via ISA
4. Often enterprise SharePoint solution interact with external system via BDC (Trying to figure out what's the difference between 2007 BDC and 2010 BCS?)
We need to plan how we can provide access to these external system in case of failover.
That means extensive communication with teams who support such system.
In my example, we accumulate all external systems calls via web services developed on BizTalk server. From our side, we need to configure ISA to have additional BizTalk availabled on the Secondary datacenter.
5.On SQL side - we are implementing async mirroring. In case primary goes down, we don't have any loss and ready to switch to the Secondary.
I prefer to have a witness on the Secondary based on assumption that we use Secondary in case Primary is down, not vice versa.
In case report db servers fail in the Primary, we need to have extra work from front-ent side. Report connection files have connection information inside them. We need to make sure that all connection files have alias name instead of the actual. In the case of failover, we just modifing alias on Report server side. Keep in the mind that SSAS type of connection file won't work with SQL alias and we can do it via host file.
We need to setup failover settings for SharePoint databases.
Refer to this post for what can be mirrored in SharePoint 2010:
The 2010 SharePoint databases, purposes and mirroring supportability
You will find that some of the SharePoint DBs are not required and are not design to setup for failover since they are not critical and easy to re-create.
Based on what recover time you have , adjust for yourself what needs to be configured with failover and what can be omitted. If a SharePoint db is not configured with failover, plan ahead what necessarily actions you should pefrom to put the bd back in case of failure, and what impact will be if the db is not ready right away. As an example, most likely the StateService will not be in high demand right after switching to the reserved (Secondary) datacenter.
Here is an outline plan how to introduce HA in SharePoint 2010 farm gradually:
1. Decide how many additional servers are needed, and their configuration.
2. WFE. Test first without including in ISA. Then include in the prod farm.
3. App server. Build the server cautiously. I believe once the app server is joined, it will used by prod WFE. No ISA configuration is needed. All requests goes from the SharePoint farm configuration directly.
4. Work on external systems HA
5. Work on SQL servers, failover settings on SharePoint side
6. SSRS servers
Wish you happy HA to you.
Friday, June 22, 2012
"SharePoint 2007 to 2010 Upgrade" online project (part 10) : Upgrade strategy plan
As it's been recommended by Joel Oleson's, we choose a Hybrid upgrade approach
Here is an actual upgrade strategy plan, that I have created before getting my hands dirty with testing and upgrading:
1. SP 2007 Prod analysis
- Topology.
Topology review showed us that we need to change topology for a new farm to increase performance.
We moved a SSRS server out of the WFEs.
- Hardware.
Check if you need to upgrade the hardware before the SP2010 upgrade
We had to upgrade all servers in the farm.
We requested a new VMs with appropriate hardware. The old 2007 farm servers will be upgraded
and we will re-use them to make the farm Highly Available.
- Configuration (external system dependency, ISA configuration)
For an example, after we rolled SP2010 out, we have discovered that current VPN client won't support popup windows in the IE...and SP2010 extensively uses Dialog forms.
Make sure that you thought over all the systems that are using the SharePoint to avoid our mistake. These dependencies should be tested with test SP2010 farm before going live.
- Customization
To pull all wsp files use the script spExtractSolutionsFromFarm.
Check if you have third-party tools that you have to migrate over.
- Recommendation
This chapter helps to formulate the scope of the work to present to project manager\customer.
2. Preparation for SP2010 upgrade
Here are the actual stages that we gone through to make 2010 Upgrade happen:
Stage I: “Pruning”. We need to prepare Prod environment before the actual upgrade. By pruning I mean removing all rudiments that are not used or not proper installed on the current Prod.
Stage II: "Build a new SP2010 farm"
1. Get new machines that meet hardware requirements for SharePoint 2010
2. Install SP2010 on the new Prod farm
3. Build topology
4. Configure service applications
Pay close attention to User Profile Synchronization service .
If you have BDC, decide whether you want to convert them into new BDCM models or not.
Depends on your decision, you need \ don't need to run Application Registry Service.
5. Deploy all custom SP2007 wsp files that needed (use the script spExtractSolutionsFromFarm )
Deploy old 2007 wsp file to check what's needed to be fixed to be compatible with SP2010.
For us, it was a big chunk of the functionality that used old BDC API.
Stage III: Test database attach upgrade on the new SP2010 farm
Document all errors that you have experienced during the upgrade, and their resolution. I have used wiki template in SharePoint for easy reference.
Stage IV: Test phase.
1. Build SP2010 farm in the testing region.
I have re-used old VMs, first requesting the up-scale for them
2. Perform the steps from 2-5 on the Test environment
3. Test\Development cycle
Should include iterations for development and re-testing
It took 3 months for us.
Stage V: Run the full cycle of the SP2010 upgrade sequentially for all environments except Prod
Ex: Development, Staging, Training
3: Prod upgrade to SP2010
Helpful to specify assumptions prior the actual upgrade:
All customizations were delivered on Prod through wsp files.
All custom solutions are SharePoint 2010 compatible
Test-SPContentDatabase check doesn’t show errors
By this time you can do upgrade with closed eyes.
We didn't get any unknown issues. All have been known before since we ran the scenario 5 times already.
1. Set read-only acces on the old Prod
2 . Backup SP2007 content database
3. Attach SP2007 database to a new SP2010 Farm
4. Run all actions that are needed after upgrade
We had a action upgrade plan, where we put the action that's needed to be taken during the upgrade and after.We put time to perform the operation and a responsible person for it.
It was like a lauching a shuttle, with only one exception - we knew it will launch without failure)
5. Validation
6. Switch ISA to a new farm
7. Keep SP2007 prod for several weeks to test issues that will be reported by end-user. It will give you a clear answer if the issue is new in SP2010 or it was present before in 2007.
Voila, you did it!
Here is an actual upgrade strategy plan, that I have created before getting my hands dirty with testing and upgrading:
1. SP 2007 Prod analysis
- Topology.
Topology review showed us that we need to change topology for a new farm to increase performance.
We moved a SSRS server out of the WFEs.
- Hardware.
Check if you need to upgrade the hardware before the SP2010 upgrade
We had to upgrade all servers in the farm.
We requested a new VMs with appropriate hardware. The old 2007 farm servers will be upgraded
and we will re-use them to make the farm Highly Available.
- Configuration (external system dependency, ISA configuration)
For an example, after we rolled SP2010 out, we have discovered that current VPN client won't support popup windows in the IE...and SP2010 extensively uses Dialog forms.
Make sure that you thought over all the systems that are using the SharePoint to avoid our mistake. These dependencies should be tested with test SP2010 farm before going live.
- Customization
To pull all wsp files use the script spExtractSolutionsFromFarm.
Check if you have third-party tools that you have to migrate over.
- Recommendation
This chapter helps to formulate the scope of the work to present to project manager\customer.
2. Preparation for SP2010 upgrade
Here are the actual stages that we gone through to make 2010 Upgrade happen:
Stage I: “Pruning”. We need to prepare Prod environment before the actual upgrade. By pruning I mean removing all rudiments that are not used or not proper installed on the current Prod.
Stage II: "Build a new SP2010 farm"
1. Get new machines that meet hardware requirements for SharePoint 2010
2. Install SP2010 on the new Prod farm
3. Build topology
4. Configure service applications
Pay close attention to User Profile Synchronization service .
If you have BDC, decide whether you want to convert them into new BDCM models or not.
Depends on your decision, you need \ don't need to run Application Registry Service.
5. Deploy all custom SP2007 wsp files that needed (use the script spExtractSolutionsFromFarm )
Deploy old 2007 wsp file to check what's needed to be fixed to be compatible with SP2010.
For us, it was a big chunk of the functionality that used old BDC API.
Stage III: Test database attach upgrade on the new SP2010 farm
Document all errors that you have experienced during the upgrade, and their resolution. I have used wiki template in SharePoint for easy reference.
Stage IV: Test phase.
1. Build SP2010 farm in the testing region.
I have re-used old VMs, first requesting the up-scale for them
2. Perform the steps from 2-5 on the Test environment
3. Test\Development cycle
Should include iterations for development and re-testing
It took 3 months for us.
Stage V: Run the full cycle of the SP2010 upgrade sequentially for all environments except Prod
Ex: Development, Staging, Training
3: Prod upgrade to SP2010
Helpful to specify assumptions prior the actual upgrade:
All customizations were delivered on Prod through wsp files.
All custom solutions are SharePoint 2010 compatible
Test-SPContentDatabase check doesn’t show errors
By this time you can do upgrade with closed eyes.
We didn't get any unknown issues. All have been known before since we ran the scenario 5 times already.
1. Set read-only acces on the old Prod
2 . Backup SP2007 content database
3. Attach SP2007 database to a new SP2010 Farm
4. Run all actions that are needed after upgrade
We had a action upgrade plan, where we put the action that's needed to be taken during the upgrade and after.We put time to perform the operation and a responsible person for it.
It was like a lauching a shuttle, with only one exception - we knew it will launch without failure)
5. Validation
6. Switch ISA to a new farm
7. Keep SP2007 prod for several weeks to test issues that will be reported by end-user. It will give you a clear answer if the issue is new in SP2010 or it was present before in 2007.
Voila, you did it!
Thursday, June 21, 2012
SharePoint: How to build SharePoint application wrong. SharePoint Karma
Whenever I refer to SharePoint development strategies, I always end up with SharePoint deployment strategies.
I am aware that in SharePoint world there are people who prefer to do customization via SPD and without a traditional development cycle.
This post for others... who wants to preserve a development cycle and who wants to have a fully automated and predictable deployment:
- via wsp files (or sandbox solution)
- and specific actions (like a feature activation) which is shipped as PowerShell\stsadm commands. (Best Practices: Sharepoint Application Development Life Cycle)
How do you choose between content customization and code-based approach?
If you need to deploy anything on the server, that's a sign that's your approach is code-based customization.
Here is a quick SharePoint karma guide for code-driven development for SharePoint. Each wrong action will lead to a specific strong deployment reaction.
All described actions I saw done by developers. I hope this quick guide helps you to avoid pain of SharePoint deployment.
Action: Create a site locally manually. And then develop some other features.
Reaction: Deployment will be hard to other environments. You will need to re-create a site manually and hope that you haven't skip any steps.
Recommended action: create a custom site definition(onet file).It was a recommended approach since 2007. But I heard it's not what will be recommended in SharePoint 15. In SharePoint 2010 you have 2 options:
- a web template that is shipped via sandbox solution and placed in the content db;
- a site definition that is shipped via wsp file and deployed on the server.
Custom web templates (the preferred approach) and custom site definitions (which in some scenarios you must do)
Action: Create stp to deploy first version of the site. You know that in the future you need to change the site structure.
Reaction: Once you have created a site from a template, there is no way you can change structure via stp
Recommended action: Use site definition and feature stapling approach for further releases. In SP2010 you can make the changes for some features that is shipped via site definition using Feature Upgrade
Action: Build a wsp, place in it only eventreceivers for specific list with expectation that the list will have appropriate structure (someone should change the structure of list and then register the eventreceiver)
Reaction: As you can guess by action, you will not have stable behavior on the environment,since half of the deployment should be performed manually. I can only hope that you keep your deployment documentation up to date.
Recommended action: If you need to develop an eventreciever for the list that should have specific fields or content type, you should describe the list in the list template feature. Package the list template, list template instance and eventreciever register features as a bundle in wsp file.
Action: Every time is time for deployment - create a new site as a blank site - and create all object manually, copy files from original site to the destination and than replace hard-coded id in the file - manually
Reaction: It's messy and prone to errors. There is no way to make such site automatic deployable
Recommended action: consider best practices of SharePoint development, use packages to deploy and feature upgrade for further releases. In case you need make some data structure changes - use SharePoint object model, write the code and package as a ReleaseFeature ( Feature stapling). This approach will allow you to keep track of all your structure changes on the existing site, plus you still can use the site definition to create a new site, and after the creation the feature stapling will do change work as it did for the existing one.
Action: Manually copy to the environment all custom master pages and customized OTB SPD web parts
Reaction: It's messy and prone to errors. There is no way to make such site automatic deployable
Recommended action: Package master pages in a feature to deliver to the server.
Regarding OTB SPD web part -there is no easy way, since the web part holds the id of the specific object from where the data is pulled. So this object will not be valid on other environment ( but in case you have developed on the copy of the prod content db, you are fine)
We have decided to develop a custom feature receiver to deploy such web parts - File provisioning: a hard-coded list id replacement
Action: Deploy report files with data source - a list asmx with hard coded List ID
Reaction: If you developed the data source (a list) that doesn't have the same id as in prod, you will have to manually change the data source after deployment.
Recommended action: To make it transportable - you can think of msi installer with parameters to swap hard coded value to a new one.
Action: Create a site groups manually and have the logic that gets these groups by IDs
Reaction: It’s prone to errors. If someone delete the group and then create a new one with the same name. You hardcoded value in the logic will break.
Recommended approach: Try the approach:
- create custom code feature which creates the groups. In the logic verifies if the custom groups exist and the permissions for them are right. If the groups don't exist, re-created them in the code.
Action: Create your own field as a counter that looks at id and has some increment value in the config file. Every time user deletes the records, you have to change the increment value in the config file.
Reaction: What???
Recommendation: I saw such application that works several years in the Prod with regular request from developer to change the increment. Last time I have checked the increment was gravitating to number 42)).
So never do such thing. This is approach is plain wrong. If you need,for some reasons, to keep ids for list items in strict order and you don't want to skip a number even though the user deletes the item and your next SharePoint id will not be subsequent to previous one, consider:
- to create a calculated field;
- to implement event receiver on the updated\created to keep the counter up to date.
And overall bad actions:
Action: Developer's objection: “It’s working on my local machine, so it is supposed to work everywhere”
Reaction: Depends on how you thought about implementation plan (if any), you may end up with the code that will work nowhere except your local machine.
Recommendation: Before you start coding for SharePoint, think through how you see your changes will be deployed.
Action: Administrator's easy fix: “If on the feature on the Prod gives you a headache - uninstall the feature”
Reaction: Some sites will may lose the functionality that they needed from uninstalled feature.
Recommendation: Analyze what uses this feature
Action: Project manager accusation\question: "This is sign of careless and sloppy work. How can we fix it?"
Reaction: A team will not collaborate to fix the issue since they are considered careless and lazy
Recommendation: Respect the work of others, be aware the world is not perfect, we are here to make it work at some extend. Ask you question in the polite way to get a faster and constructive answer.
Good deeds to you and light consequences.
I am aware that in SharePoint world there are people who prefer to do customization via SPD and without a traditional development cycle.
This post for others... who wants to preserve a development cycle and who wants to have a fully automated and predictable deployment:
- via wsp files (or sandbox solution)
- and specific actions (like a feature activation) which is shipped as PowerShell\stsadm commands. (Best Practices: Sharepoint Application Development Life Cycle)
How do you choose between content customization and code-based approach?
If you need to deploy anything on the server, that's a sign that's your approach is code-based customization.
Here is a quick SharePoint karma guide for code-driven development for SharePoint. Each wrong action will lead to a specific strong deployment reaction.
Action: Create a site locally manually. And then develop some other features.
Reaction: Deployment will be hard to other environments. You will need to re-create a site manually and hope that you haven't skip any steps.
Recommended action: create a custom site definition(onet file).It was a recommended approach since 2007. But I heard it's not what will be recommended in SharePoint 15. In SharePoint 2010 you have 2 options:
- a web template that is shipped via sandbox solution and placed in the content db;
- a site definition that is shipped via wsp file and deployed on the server.
Custom web templates (the preferred approach) and custom site definitions (which in some scenarios you must do)
Action: Create stp to deploy first version of the site. You know that in the future you need to change the site structure.
Reaction: Once you have created a site from a template, there is no way you can change structure via stp
Recommended action: Use site definition and feature stapling approach for further releases. In SP2010 you can make the changes for some features that is shipped via site definition using Feature Upgrade
Action: Build a wsp, place in it only eventreceivers for specific list with expectation that the list will have appropriate structure (someone should change the structure of list and then register the eventreceiver)
Reaction: As you can guess by action, you will not have stable behavior on the environment,since half of the deployment should be performed manually. I can only hope that you keep your deployment documentation up to date.
Recommended action: If you need to develop an eventreciever for the list that should have specific fields or content type, you should describe the list in the list template feature. Package the list template, list template instance and eventreciever register features as a bundle in wsp file.
Reaction: It's messy and prone to errors. There is no way to make such site automatic deployable
Recommended action: consider best practices of SharePoint development, use packages to deploy and feature upgrade for further releases. In case you need make some data structure changes - use SharePoint object model, write the code and package as a ReleaseFeature ( Feature stapling). This approach will allow you to keep track of all your structure changes on the existing site, plus you still can use the site definition to create a new site, and after the creation the feature stapling will do change work as it did for the existing one.
Action:Write a code to send an email\interact with end-users without environment variables
Reaction: If you miss configuration settings for your interactive logic, you miss control over it. You may end up with end-user notification sent while you are testing the application.
Recommended action: Choose approach that suits your needs best:
- web.config file custom section ( One of the way to use web.config SharePoint Configuration Values Best Practices);
- property bag on the specific object (site, list, item ,etc ) (One of the way how to handle the property bag - SharePoint Property Bag Settings 2010)
- hidden list with environment variables.
Reaction: It's messy and prone to errors. There is no way to make such site automatic deployable
Recommended action: Package master pages in a feature to deliver to the server.
Regarding OTB SPD web part -there is no easy way, since the web part holds the id of the specific object from where the data is pulled. So this object will not be valid on other environment ( but in case you have developed on the copy of the prod content db, you are fine)
We have decided to develop a custom feature receiver to deploy such web parts - File provisioning: a hard-coded list id replacement
Reaction: If you developed the data source (a list) that doesn't have the same id as in prod, you will have to manually change the data source after deployment.
Recommended action: To make it transportable - you can think of msi installer with parameters to swap hard coded value to a new one.
Action: Create a site groups manually and have the logic that gets these groups by IDs
Reaction: It’s prone to errors. If someone delete the group and then create a new one with the same name. You hardcoded value in the logic will break.
Recommended approach: Try the approach:
- create custom code feature which creates the groups. In the logic verifies if the custom groups exist and the permissions for them are right. If the groups don't exist, re-created them in the code.
Action: Create your own field as a counter that looks at id and has some increment value in the config file. Every time user deletes the records, you have to change the increment value in the config file.
Reaction: What???
Recommendation: I saw such application that works several years in the Prod with regular request from developer to change the increment. Last time I have checked the increment was gravitating to number 42)).
So never do such thing. This is approach is plain wrong. If you need,for some reasons, to keep ids for list items in strict order and you don't want to skip a number even though the user deletes the item and your next SharePoint id will not be subsequent to previous one, consider:
- to create a calculated field;
- to implement event receiver on the updated\created to keep the counter up to date.
And overall bad actions:
Action: Developer's objection: “It’s working on my local machine, so it is supposed to work everywhere”
Reaction: Depends on how you thought about implementation plan (if any), you may end up with the code that will work nowhere except your local machine.
Recommendation: Before you start coding for SharePoint, think through how you see your changes will be deployed.
Action: Administrator's easy fix: “If on the feature on the Prod gives you a headache - uninstall the feature”
Reaction: Some sites will may lose the functionality that they needed from uninstalled feature.
Recommendation: Analyze what uses this feature
Action: Project manager accusation\question: "This is sign of careless and sloppy work. How can we fix it?"
Reaction: A team will not collaborate to fix the issue since they are considered careless and lazy
Recommendation: Respect the work of others, be aware the world is not perfect, we are here to make it work at some extend. Ask you question in the polite way to get a faster and constructive answer.
Good deeds to you and light consequences.
Thursday, March 22, 2012
Simple concept: when to use Reporting Services (SSRS) and when to use PerformancePoint Services 2010
[Question]:
When to use SQL Server Reporting Services (SSRS) and when to use PerformancePoint Services 2010"?
[Answer]:
PerformancePoint Services excels in the creation of KPIs and scorecards. If you need other type of reports (tabular, interactive, visual, or freeform), you will need SQL Server Reporting Services (SSRS).
When to use SQL Server Reporting Services (SSRS) and when to use PerformancePoint Services 2010"?
[Answer]:
PerformancePoint Services excels in the creation of KPIs and scorecards. If you need other type of reports (tabular, interactive, visual, or freeform), you will need SQL Server Reporting Services (SSRS).
Subscribe to:
Posts (Atom)