When:
Saturday, September 25th, 2010
Where:
Microsoft Corporation
201 Jones Road
6th Floor
Waltham, MA 02451
Friday, July 30, 2010
Event: SharePoint Saturday Boston 2010
SharePoint Saturday Boston, 2010 (#3)
When:
Saturday, September 25th, 2010
Where:
Microsoft Corporation
When:
Saturday, September 25th, 2010
Where:
Microsoft Corporation
Three SQL Server Settings for SharePoint Environments: Autogrowth Option, Auto Shrink Option, Shrink Database Task
As I was tuning a SharePoint environment today, I thought it would be a good opportunity to post a brief message about three SQL Server settings: Autogrowth, Auto Shrink, and the Shrink Database Task.
1. Autogrowth - Fixed Amount:
This setting applies to data files (.mdf) and transaction log files (.ldf). Autogrowth allows or prevents SQL Server from automatically increasing the size of the files when the need arises. In SharePoint environments, it is best to do capacity planning in advance and set the intial database sizes appropriately. Then, set the Autogrowth value for both the data files and the log files to a fixed amount. This ensures that the files grow in consistent increments. The fixed amount should be somewhat substantial, relative to the size of the database. This ensures that the growth does not occur too frequently.
2. Auto Shrink - Turn it Off:
Auto Shrink is an option that allows or prevents SQL Server from automatically reducing the size of database files. By default, the SQL Server Model database has the Auto Shrink option off. As Paul Randal points out, enabling Auto Shrink can lead to Auto-Grow, Auto-Shrink loops as well as database fragmentation, and other performance issues (Randal, 2007). As a general rule of thumb for most SharePoint environments, this option should remain off for system and content databases.
3. Shrink Database Task - Don't Schedule It:
The Shrink Database Task is an available Maintenance Plan Task. If set, this operation will reduce the size of a database according to a schedule, leaving a specified amount of free space. As with the Auto Shrink option, the Shrink Database Task leads to performance issues and is not recommend in SharePoint environments.
So, if an existing SharePoint environment does have a scheduled Shrink Database Task, then a suggested action would be to remove the Shrink Database Task and then plan to monitor and manage database size using a manual approach. When determining a plan for managing database size, it is important to keep Database Recovery Models in mind.
Reference
Randal, P. (August, 2008). Top Tips for Effective Database Maintenance. Retrieved July 30, 2010 from http://technet.microsoft.com/en-us/magazine/2008.08.database.aspx?pr=blog.
Randal, P. (March, 2007). Turn AUTO_SHRINK off!! Retrieved July 30, 2010 from http://blogs.msdn.com/b/sqlserverstorageengine/archive/2007/03/28/turn-auto-shrink-off.aspx.
1. Autogrowth - Fixed Amount:
This setting applies to data files (.mdf) and transaction log files (.ldf). Autogrowth allows or prevents SQL Server from automatically increasing the size of the files when the need arises. In SharePoint environments, it is best to do capacity planning in advance and set the intial database sizes appropriately. Then, set the Autogrowth value for both the data files and the log files to a fixed amount. This ensures that the files grow in consistent increments. The fixed amount should be somewhat substantial, relative to the size of the database. This ensures that the growth does not occur too frequently.
2. Auto Shrink - Turn it Off:
Auto Shrink is an option that allows or prevents SQL Server from automatically reducing the size of database files. By default, the SQL Server Model database has the Auto Shrink option off. As Paul Randal points out, enabling Auto Shrink can lead to Auto-Grow, Auto-Shrink loops as well as database fragmentation, and other performance issues (Randal, 2007). As a general rule of thumb for most SharePoint environments, this option should remain off for system and content databases.
3. Shrink Database Task - Don't Schedule It:
The Shrink Database Task is an available Maintenance Plan Task. If set, this operation will reduce the size of a database according to a schedule, leaving a specified amount of free space. As with the Auto Shrink option, the Shrink Database Task leads to performance issues and is not recommend in SharePoint environments.
So, if an existing SharePoint environment does have a scheduled Shrink Database Task, then a suggested action would be to remove the Shrink Database Task and then plan to monitor and manage database size using a manual approach. When determining a plan for managing database size, it is important to keep Database Recovery Models in mind.
Reference
Randal, P. (August, 2008). Top Tips for Effective Database Maintenance. Retrieved July 30, 2010 from http://technet.microsoft.com/en-us/magazine/2008.08.database.aspx?pr=blog.
Randal, P. (March, 2007). Turn AUTO_SHRINK off!! Retrieved July 30, 2010 from http://blogs.msdn.com/b/sqlserverstorageengine/archive/2007/03/28/turn-auto-shrink-off.aspx.
Tuesday, July 27, 2010
Why Information Silos Are So Persistent
Information silos are disparate entities that exist as rogue systems, utilities, spreadsheets and Access databases. Actually, an information silo might be anything that is not centrally managed or does not conform to existing design patterns. Silos may or may not be considered an official part of the enterprise...awareness about the silo doesn't change its definition.
Most of the time, these tools were developed to fill a gap. A gap between what the enterprise offers and what certain areas of the business actually need to function. They serve a purpose; and in many cases they are significant to the processes that they support.
Considering where technology is today, why are are information silos so persistent, more prevalent than ever? Why can't IT just build something into the enterprise architecture?
One reason (or cause) is because of the technology, which has become easier to work with and more accessible to people inside and outside of IT Departments. A person of any role can go on the Internet and figure out how to set up an Access database. In many cases, this is much easier than approaching a centralized IT department with their requirements. The Internet isn't going to say "no." By circumventing IT, nobody asks for funding, tries to minimize or question the need, or compromise the intention in any way. But, if the request did go to the IT department might, there might be resistance.
Secondly, a rogue solution is much less risky for a business person in terms of exposure and process transparency. By setting up a tool of their own, a business person may struggle a bit with configuration, but at no point is their process going to be visible to other people for criticism. If the person was to bring their requirements to the table and ask for help, then a lot of questions might be asked, putting guarded knowledge at risk. Unfortunately, for protective types, this means that the process would, in fact, become more transparent. The original process owner would become a "stakeholder" with influence rather than an "owner" with full control.
Beyond that, information silos also exist when an organization's methodologies and practices for providing holistic solutions are not mature enough to truly help. For example, IT organizations which are disorganized and reactive, might not be capable of helping the business person with their needs. There's no process, no authority, no plan to handle this sort of thing.
All of these situations challenge a centralized Information Management strategy.
Most of the time, these tools were developed to fill a gap. A gap between what the enterprise offers and what certain areas of the business actually need to function. They serve a purpose; and in many cases they are significant to the processes that they support.
Considering where technology is today, why are are information silos so persistent, more prevalent than ever? Why can't IT just build something into the enterprise architecture?
One reason (or cause) is because of the technology, which has become easier to work with and more accessible to people inside and outside of IT Departments. A person of any role can go on the Internet and figure out how to set up an Access database. In many cases, this is much easier than approaching a centralized IT department with their requirements. The Internet isn't going to say "no." By circumventing IT, nobody asks for funding, tries to minimize or question the need, or compromise the intention in any way. But, if the request did go to the IT department might, there might be resistance.
Secondly, a rogue solution is much less risky for a business person in terms of exposure and process transparency. By setting up a tool of their own, a business person may struggle a bit with configuration, but at no point is their process going to be visible to other people for criticism. If the person was to bring their requirements to the table and ask for help, then a lot of questions might be asked, putting guarded knowledge at risk. Unfortunately, for protective types, this means that the process would, in fact, become more transparent. The original process owner would become a "stakeholder" with influence rather than an "owner" with full control.
Beyond that, information silos also exist when an organization's methodologies and practices for providing holistic solutions are not mature enough to truly help. For example, IT organizations which are disorganized and reactive, might not be capable of helping the business person with their needs. There's no process, no authority, no plan to handle this sort of thing.
All of these situations challenge a centralized Information Management strategy.
Saturday, July 24, 2010
General Business Requirements vs. Solution Requirements
What came first, the solution or the need? Let's hope the need, but we all know that is not always (often not) the case. With the great technologies available to us today, rapid application development enables us to solve problems. But, does the ease of development actually create a new set of problems? Yes, it does.
When the software development process is lengthy and drawn out, it forces many planning activities such as requirements analysis, design specifications, and planning. Not doing these things leads to costly adjustments later. The lengthy process also forces organizations to really think about what solutions they are developing and how these solutions fit into the big picture. We've got it pretty easy today. With portals, collaboration, search, BI, content management, and workflow platforms today, some times doing it "wrong", undoing it, and doing it again is actually less expensive than the cost of planning and documenting.
Yes, I am familiar with the twelve principles of the Agile Manifesto (Agile Alliance, 2001). I like agile development when it follows some organized processes and produces artifacts that can be used for reference later. You still need documentation for future development, disaster recovery, and repair.
However, what I don't like is "premature solutioning" or the practice of directly jumping from a problem to a solution design without any sort of further questioning, analysis, thought, or sanity checks. When you encounter a problem, and immediately form a solution and begin developing it, a lot is lost. You are not considering what other stakeholder needs are, what other colleagues are already working on, and how this "fly by the seat of your pants" solution actually fits in (or doesn't) into your overall information architecture.
Working with my colleagues, we recently began formalizing our thoughts around the solutioning process. One of the first roadblocks we encountered had to do with semantics. We began observing that our push for "requirements" was being misunderstood. When a problem-solution situation arose, we would explain that we needed to analyze requirements. The response to this typically included design specifications. We would then stop and say, no, we don't want detailed design specifications, what we want is to understand the problem better and understand how it impacts other people, so we can create a solution that will fit into our information architecture in a way that adds value and doesn't undermine anything else we are doing.
After a few more of these scenarios we decided that we had to make others aware of our solutioning process and how we think, so that everybody would be able to communicate with each other better. The first thing we did was make a distinction between the types of requirements that we would discuss in the course of solutioning.
We decided on the following:
General Business Requirements - Facts and opinions that help understand the problem better. These are not design specifications and do not explain a solution. Instead, this information explains what the business needs are.
Solution Requirements - Facts and opinions that define how a solution is supposed to look, feel, or act. This information directly dictates the design specifications.
So, now when a new request arises, we start by gathering "general business requirements." We then consult with stakeholders, policies, procedures, standards, goals, etc. and analyze the information. Once we have all the facts, we begin to design a solution. At that time, we ask stakeholders to help us define the "solution requirements." The result of the latter activity is a design specifications document. Next, we schedule and plan the development activities and proceed from there.
Reference
Agile Alliance (2001). Principles Behind the Agile Manifesto. Retrieved July 24, 2010 from http://agilemanifesto.org/principles.html.
When the software development process is lengthy and drawn out, it forces many planning activities such as requirements analysis, design specifications, and planning. Not doing these things leads to costly adjustments later. The lengthy process also forces organizations to really think about what solutions they are developing and how these solutions fit into the big picture. We've got it pretty easy today. With portals, collaboration, search, BI, content management, and workflow platforms today, some times doing it "wrong", undoing it, and doing it again is actually less expensive than the cost of planning and documenting.
Yes, I am familiar with the twelve principles of the Agile Manifesto (Agile Alliance, 2001). I like agile development when it follows some organized processes and produces artifacts that can be used for reference later. You still need documentation for future development, disaster recovery, and repair.
However, what I don't like is "premature solutioning" or the practice of directly jumping from a problem to a solution design without any sort of further questioning, analysis, thought, or sanity checks. When you encounter a problem, and immediately form a solution and begin developing it, a lot is lost. You are not considering what other stakeholder needs are, what other colleagues are already working on, and how this "fly by the seat of your pants" solution actually fits in (or doesn't) into your overall information architecture.
Working with my colleagues, we recently began formalizing our thoughts around the solutioning process. One of the first roadblocks we encountered had to do with semantics. We began observing that our push for "requirements" was being misunderstood. When a problem-solution situation arose, we would explain that we needed to analyze requirements. The response to this typically included design specifications. We would then stop and say, no, we don't want detailed design specifications, what we want is to understand the problem better and understand how it impacts other people, so we can create a solution that will fit into our information architecture in a way that adds value and doesn't undermine anything else we are doing.
After a few more of these scenarios we decided that we had to make others aware of our solutioning process and how we think, so that everybody would be able to communicate with each other better. The first thing we did was make a distinction between the types of requirements that we would discuss in the course of solutioning.
We decided on the following:
General Business Requirements - Facts and opinions that help understand the problem better. These are not design specifications and do not explain a solution. Instead, this information explains what the business needs are.
Solution Requirements - Facts and opinions that define how a solution is supposed to look, feel, or act. This information directly dictates the design specifications.
So, now when a new request arises, we start by gathering "general business requirements." We then consult with stakeholders, policies, procedures, standards, goals, etc. and analyze the information. Once we have all the facts, we begin to design a solution. At that time, we ask stakeholders to help us define the "solution requirements." The result of the latter activity is a design specifications document. Next, we schedule and plan the development activities and proceed from there.
Reference
Agile Alliance (2001). Principles Behind the Agile Manifesto. Retrieved July 24, 2010 from http://agilemanifesto.org/principles.html.
Thursday, July 22, 2010
SharePoint 4.0: Summary Links Data Column Type
In SharePoint, there is a column type called, "Summary Links Data." Microsoft desribes this column type as "Columns that represent summary links for a page. Summary Links include a title, description, image, and URL and are used on publishing pages to present grouped links by using a set of shared styles" (Microsoft, 2010).
This column type is brilliant in theory, but unfortunately they don't appear to work as expected. Here is my assessment of the Summary Links Data column type.
In SharePoint 2010, if I add a Summary Links Data column to document library, then add a new document, the new or edit document properties page looks correct. The Summary Links Data column is represented by an editable summary links control.
Reference
This column type is brilliant in theory, but unfortunately they don't appear to work as expected. Here is my assessment of the Summary Links Data column type.
In SharePoint 2010, if I add a Summary Links Data column to document library, then add a new document, the new or edit document properties page looks correct. The Summary Links Data column is represented by an editable summary links control.
However, after the links have been added and the document uploaded, you return to the document properties using the "View Properties" page. The result of this is that the links are not visible. Huh?
OK, so let's try a custom list. Added the column to a custom list. Adding or editing an item results in a non-editable field. So, the Summary Data List story just got even worse in custom lists...
Reference
Microsoft (2010). Create a site column. Retrieved July 22, 2010 from http://office.microsoft.com/en-us/sharepoint-server-help/create-a-site-column-HA010177759.aspx.
Site Columns: SharePoint 2010 vs. SharePoint 2007
When comparing the "create site column" screen of SharePoint 2010 versus the one in SharePoint 2007, the features are mostly similar except for three enhancements in 2010. These include:
1. Column types for Rich Media and Managed Metadata.
2. "Enforce unique values."
3. Column validation.
(Microsoft, 2010)
During the past few years, I do remember occasions when I was "wishing" for the ability to apply unique permissions at the site column or content type level, but these abilities are not something available in SharePoint 2010.
I imagine field level or content type security would require a more dynamic design at the list and library level, since the list and libraries still work off the static template model, storing their own column definitions in XML as they were defined at the time of list or library creation, and maintaining their own security settings. This is evident when you delete a site column that is being used in a list or library. The site column is removed from the site column gallery, but a local instance of it still remains on the list or library.
In order for field level or content type security to be possible in SharePoint, each site column and local column definition would need to be expanded to include a security definition. List and library views would also need to become more security aware, rendering different columns based on varying security contexts. So, pushing down unique site column or content type security is more than the platform can handle at this time.
Microsoft SharePoint Server 2010
Microsoft Office SharePoint Server 2007
Microsoft (2010). Introduction to Columns. Retrieved July 22, 2010 from http://msdn.microsoft.com/en-us/library/ms450825.aspx.
1. Column types for Rich Media and Managed Metadata.
2. "Enforce unique values."
3. Column validation.
(Microsoft, 2010)
During the past few years, I do remember occasions when I was "wishing" for the ability to apply unique permissions at the site column or content type level, but these abilities are not something available in SharePoint 2010.
I imagine field level or content type security would require a more dynamic design at the list and library level, since the list and libraries still work off the static template model, storing their own column definitions in XML as they were defined at the time of list or library creation, and maintaining their own security settings. This is evident when you delete a site column that is being used in a list or library. The site column is removed from the site column gallery, but a local instance of it still remains on the list or library.
In order for field level or content type security to be possible in SharePoint, each site column and local column definition would need to be expanded to include a security definition. List and library views would also need to become more security aware, rendering different columns based on varying security contexts. So, pushing down unique site column or content type security is more than the platform can handle at this time.
Microsoft SharePoint Server 2010
Microsoft Office SharePoint Server 2007
Reference
Microsoft (2010). Create a site column. Retrieved July 22, 2010 from http://office.microsoft.com/en-us/sharepoint-server-help/create-a-site-column-HA010177759.aspx.Microsoft (2010). Introduction to Columns. Retrieved July 22, 2010 from http://msdn.microsoft.com/en-us/library/ms450825.aspx.
Wednesday, July 21, 2010
Fiddler
A gentleman named Eric Lawrence has developed a very useful Web debugging tool named, Fiddler. The Fiddler Web site is http://www.fiddler2.com/fiddler2/version.asp. I've used this tool recently to pinpoint performance issues, security issues, and authentication issues.
"Fiddler is an HTTP debugging proxy written by Eric Lawrence of Microsoft.[1] It seamlessly captures HTTP traffic and logs it for the user to review.[4] It can also be used to "fiddle" with HTTP traffic as it is being sent.[3] By default, traffic from Microsoft's WinINET HTTP(S) stack is automatically directed through Fiddler at runtime, but any browser or application can be configured to route traffic through Fiddler.
The new version, known as Fiddler2, offers support for interception and tampering with HTTPS traffic." (Wikipedia, 2010)
To install Fiddler, follow these steps:
1. Download Fiddler.
2. Run the setup.exe.
To run a trace, follow these steps:
1. Open Fiddler (Start > All Programs > Fiddler2).
2. Begin a trace (File > Capture Traffic).
3. Launch Internet Explorer and produce the activity you would like to trace.
4. Stop the trace (File > uncheck Capture Traffic).
5. Save the trace file (File > Save > All Sessions).
6. Now, you are able to analyze the activity and pinpoint issues. You may also consider comparing the Fiddler trace to the Application Event log from the client and server machines.
Reference
Lawrence, E. (2010). Fiddler2 - Installation Information. Retrieved July 20, 2010 from http://www.fiddler2.com/fiddler2/version.asp.
Wikipedia (2010). Fiddler (software). Retrieved July 20, 2010 from http://en.wikipedia.org/wiki/Fiddler_(software).
Microsoft Certifications for SharePoint 2010
For the 2010 generation, the Microsoft SharePoint certifications tracks have been enhanced. Below is a breakout of the certifications available.
Microsoft Certified IT Professional (MCITP): SharePoint Administrator 2010
70-668 PRO: SharePoint Server 2010, Administrator
http://www.microsoft.com/learning/en/us/Exam.aspx?ID=70-668
70-667 TS: Microsoft SharePoint 2010, Configuring
http://www.microsoft.com/learning/en/us/Exam.aspx?ID=70-667
Microsoft Certified Professional Developer (MCPD): SharePoint Developer 2010
70-576 PRO: Designing and Developing Microsoft SharePoint 2010 Applications
http://www.microsoft.com/learning/en/us/Exam.aspx?ID=70-576
70-573 TS: Microsoft SharePoint 2010, Application Development
http://www.microsoft.com/learning/en/us/Exam.aspx?ID=70-573
Microsoft Certified Master program (MCM)
http://www.microsoft.com/learning/en/us/certification/architect.aspx
Microsoft Certified Architect certification (MCA)
http://www.microsoft.com/learning/en/us/certification/master.aspx#tab2
Reference
Microsoft (2010). Microsoft SharePoint – Training Portal. Retrieved July 21, 2010 from http://www.microsoft.com/learning/en/us/training/sharepoint.aspx.
Prometric (2010). Microsoft Certifications. Retrieved July 21, 2010 from http://www.prometric.com/Microsoft/default.htm.
Microsoft Certified IT Professional (MCITP): SharePoint Administrator 2010
70-668 PRO: SharePoint Server 2010, Administrator
http://www.microsoft.com/learning/en/us/Exam.aspx?ID=70-668
70-667 TS: Microsoft SharePoint 2010, Configuring
http://www.microsoft.com/learning/en/us/Exam.aspx?ID=70-667
Microsoft Certified Professional Developer (MCPD): SharePoint Developer 2010
70-576 PRO: Designing and Developing Microsoft SharePoint 2010 Applications
http://www.microsoft.com/learning/en/us/Exam.aspx?ID=70-576
70-573 TS: Microsoft SharePoint 2010, Application Development
http://www.microsoft.com/learning/en/us/Exam.aspx?ID=70-573
Microsoft Certified Master program (MCM)
http://www.microsoft.com/learning/en/us/certification/architect.aspx
Microsoft Certified Architect certification (MCA)
http://www.microsoft.com/learning/en/us/certification/master.aspx#tab2
Reference
Microsoft (2010). Microsoft SharePoint – Training Portal. Retrieved July 21, 2010 from http://www.microsoft.com/learning/en/us/training/sharepoint.aspx.
Prometric (2010). Microsoft Certifications. Retrieved July 21, 2010 from http://www.prometric.com/Microsoft/default.htm.
Monday, July 12, 2010
Connected Lookup on Codeplex
It is called many names; Connected Lookup, Cascading Dropdowns, Dependencies, etc. Whatever the nomenclature, the requirement to have one choice column drive the choices in a another choice drop down is an extremely common requirement in SharePoint applications.
There is a Codeplex project that I discovered today, for WSS 3.0 and MOSS 2007. I've pretty much halted future development on MOSS 2007 at this point but I thought I'd post the link regardless.
There is a Codeplex project that I discovered today, for WSS 3.0 and MOSS 2007. I've pretty much halted future development on MOSS 2007 at this point but I thought I'd post the link regardless.
Reference
Codeplex (2010). SharePoint Connected Lookup. Retrieved July 12, 2010 from http://cl.codeplex.com/.
Tuesday, July 06, 2010
Link: Process Monitor
Microsoft offers Process Monitor as a free download. In short, this tool helps capture detailed events and isolate issues. I recently used Process Monitor when I encountered a performance issue with one of my portals; the default.aspx page was taking a long time to save. Process Monitor helped me isolate the issue and determine that the cause was a buffer overflow.
Reference
Microsoft (2010). Windows Sysinternals, Process Monitor v2.91. Retrieved July 6, 2010 from http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx