I love Microsoft. No where can you expect a definitive answer.
The one article will tell you that the acceptable limit for site collections per web application is 500'000 (http://technet.microsoft.com/en-us/library/ff758647.aspx) and the next article in the same series will tell you it is 250'000 (http://technet.microsoft.com/en-us/library/cc262787.aspx)
Best of all, they both use the same wording!
"An example of a supported limit is the number of site collections per Web application. The supported limit is 500,000, which is the largest number of site collections per Web application that met performance benchmarks during testing. "
vs
"An example of a supported limit is the number of site collections per Web application. The supported limit is 250,000, which is the largest number of site collections per Web application that met performance benchmarks during testing."
In the end these limits are based on benchmark testing. I.e. when the performance of the farm starts falling below an acceptable level. It is not saying that the farm is running at top speed with 249999 site collections and then drops off. No, it is a curve. So imagine the performance curve starting high at 100%, dropping to 95% at 100'000, dropping to 90% at 250'000 and dropping to 80% at 500'000. The key question is, what is an acceptable level of performance. Looks like the author either changed his mind from one article to another, or two authors differed. In the end both are right, I guess. Because only you can define for yourself what acceptable performance is.
And don't forget, these benchmarks are tested in isolation. so when you store tens of thousands of 50MB documents in a document library hundreds of times per site and thousands of times per site collection, the 500'000 benchmark will never hold up. 50 would sound more realistic.
Thursday, September 30, 2010
How to Pass 70-667
So you wanna become SharePoint certified? At least now, with SharePoint 2010, we have the MCITP SharePoint Administrator and SharePoint Developer accreditations.
70-667 is the first of two exams to achieve your MCITP SharePoint 2010 Administrator certification
http://www.microsoft.com/learning/en/us/exam.aspx?ID=70-667
And although I can't tell you what the questions will be, let me assure you, they are not trick questions.
I'd say about half of the questions are relevant to 2007 and 2010 alike, some are 2010 specific and others are there to catch you out where something has changed from 2007 to 2010.
The best way of making sure you pass any Microsoft exam on the first go is to use practice tests. Measureup and selftest provide some really good ones for all things techie. Sadly, none of them have gotten round to publishing SharePoint 2010 mock exams yet.
The best way of making sure you fully understand the material is sitting a Microsoft course: 10174 Configuring and Administering Microsoft SharePoint Server 2010
This course contains all the stuff you need to know to feel confident about installing, configuring and running a SharePoint farm. Although officially Microsoft Courses and the exams are not directly related, there are strong overlaps of the material being taught and the questions being asked.
And here is the best news of all! I'm down to teach 10174 at Auldhouse in Wellington the week of 18/10/10.
https://www.auldhouse.co.nz/content/5f8ac4c7-9c13-4a6f-8d51-30762e93882b.html?loc=Wellington
So sign up now to get one step closer to your SharePoint 2010 certificate. I'll even dish out some tips during the course on how to tackle certain types of questions in the exam.
70-667 is the first of two exams to achieve your MCITP SharePoint 2010 Administrator certification
http://www.microsoft.com/learning/en/us/exam.aspx?ID=70-667
And although I can't tell you what the questions will be, let me assure you, they are not trick questions.
I'd say about half of the questions are relevant to 2007 and 2010 alike, some are 2010 specific and others are there to catch you out where something has changed from 2007 to 2010.
The best way of making sure you pass any Microsoft exam on the first go is to use practice tests. Measureup and selftest provide some really good ones for all things techie. Sadly, none of them have gotten round to publishing SharePoint 2010 mock exams yet.
The best way of making sure you fully understand the material is sitting a Microsoft course: 10174 Configuring and Administering Microsoft SharePoint Server 2010
This course contains all the stuff you need to know to feel confident about installing, configuring and running a SharePoint farm. Although officially Microsoft Courses and the exams are not directly related, there are strong overlaps of the material being taught and the questions being asked.
And here is the best news of all! I'm down to teach 10174 at Auldhouse in Wellington the week of 18/10/10.
https://www.auldhouse.co.nz/content/5f8ac4c7-9c13-4a6f-8d51-30762e93882b.html?loc=Wellington
So sign up now to get one step closer to your SharePoint 2010 certificate. I'll even dish out some tips during the course on how to tackle certain types of questions in the exam.
SharePoint 2010 to CAS or not to CAS
Came across a statement by MS which got me thinking
"Untrusted solutions – Deploying custom code in bin folders can cause slow server performance. Every time a page containing untrusted code is requested, SharePoint Server 2010 must perform security checks before the page can be loaded.Unless there is a specific reason to deploy untrusted code, you should install custom assemblies in the GAC to avoid unnecessary security checking."
http://technet.microsoft.com/en-us/library/ff758647.aspx
So now GAC is good and CAS is bad?
Ok folks, let's all stop adhering to a least priviledge concept and start giving our code full trust every time we deploy something. Because if we don't, we'll slow down SharePoint.
I don't think so!
Although I understand the implications of having to check security of the code when Code Access Security Policies are involved, is the overhead of checking the policy when the assembly is loaded really that high? So far I have found no evidence of this causing a noticeable performance degradation other than in theory.
But hey, we have Sandboxed solutions now! So no need for CAS?
Although Sandboxed solutions take away a lot of headache from Server Administrators that previously had to chase down developers to find out why their server just crashed, they are not the golden bullet to all security issues. The question still remains, how much do you trust the code to do what it is supposed to do and not expose loopholes for others to exploit? Especially when installing third party features I personally would think twice about putting the dlls into the GAC of my production machines.
Sadly enough, there are loads of scenarios where you have no other choice but to run the code in the GAC and thus I am very grateful for the Sandbox, where I can run the code in a controlled environment before letting it loose on the whole farm.
For those of you who actually want to know how CAS works in practice, check out this little gem. It is based on .NET 1.1, but is still relevant today.
http://msdn.microsoft.com/en-us/library/ff648663.aspx
oh, and in .NET 4.0 some things have changed in regards to CAS, especially when calling GAC assemblies from partially trusted dlls. check it out here:
http://msdn.microsoft.com/en-us/library/dd984947.aspx
"Untrusted solutions – Deploying custom code in bin folders can cause slow server performance. Every time a page containing untrusted code is requested, SharePoint Server 2010 must perform security checks before the page can be loaded.Unless there is a specific reason to deploy untrusted code, you should install custom assemblies in the GAC to avoid unnecessary security checking."
http://technet.microsoft.com/en-us/library/ff758647.aspx
So now GAC is good and CAS is bad?
Ok folks, let's all stop adhering to a least priviledge concept and start giving our code full trust every time we deploy something. Because if we don't, we'll slow down SharePoint.
I don't think so!
Although I understand the implications of having to check security of the code when Code Access Security Policies are involved, is the overhead of checking the policy when the assembly is loaded really that high? So far I have found no evidence of this causing a noticeable performance degradation other than in theory.
But hey, we have Sandboxed solutions now! So no need for CAS?
Although Sandboxed solutions take away a lot of headache from Server Administrators that previously had to chase down developers to find out why their server just crashed, they are not the golden bullet to all security issues. The question still remains, how much do you trust the code to do what it is supposed to do and not expose loopholes for others to exploit? Especially when installing third party features I personally would think twice about putting the dlls into the GAC of my production machines.
Sadly enough, there are loads of scenarios where you have no other choice but to run the code in the GAC and thus I am very grateful for the Sandbox, where I can run the code in a controlled environment before letting it loose on the whole farm.
For those of you who actually want to know how CAS works in practice, check out this little gem. It is based on .NET 1.1, but is still relevant today.
http://msdn.microsoft.com/en-us/library/ff648663.aspx
oh, and in .NET 4.0 some things have changed in regards to CAS, especially when calling GAC assemblies from partially trusted dlls. check it out here:
http://msdn.microsoft.com/en-us/library/dd984947.aspx
Saturday, May 15, 2010
Send To Email with Attachment
Sending emails with a Sharepoint document as an attachment is a commonly asked for feature in Sharepoint.
Although the mailto: link used to work with the attachment parameter, this has not been supported by Outlook for a long time. Why? because it would be too easy to attach viruses to emails that way. Outlook would have to download a file from the internet and add it to the message. The chance of malicious code injecting into the process is too risky as well as the chance to send infected files to friends and colleagues.
So what is the solution?
If you wish to extend the send to menu in SharePoint, you can create a feature with a custom action to add another link to the ECM (Context Menu) which opens up a custom application page which then allows the user to enter receiver, subject and body. The server then could send the email directly via the configured SMTP server.
But beware!
This should only be done in an intranet scenario where the sending user has been authenticated. Otherwise it could be abused for spamming purposes too easily
Although the mailto: link used to work with the attachment parameter, this has not been supported by Outlook for a long time. Why? because it would be too easy to attach viruses to emails that way. Outlook would have to download a file from the internet and add it to the message. The chance of malicious code injecting into the process is too risky as well as the chance to send infected files to friends and colleagues.
So what is the solution?
If you wish to extend the send to menu in SharePoint, you can create a feature with a custom action to add another link to the ECM (Context Menu) which opens up a custom application page which then allows the user to enter receiver, subject and body. The server then could send the email directly via the configured SMTP server.
But beware!
This should only be done in an intranet scenario where the sending user has been authenticated. Otherwise it could be abused for spamming purposes too easily
Saturday, May 1, 2010
SharePoint Memory Leak
Todd Carter has posted a great article on a nasty little memory leak in SharePoint which has the potential to blow into a huge memory consumption beast for servers which have a lot of traffic and long uptime.
http://todd-carter.com/post/2010/02/08/SharePointe28099s-Sasquatch-Memory-Leak.aspx
In his article he highlights a problem with the HttpApplicatinoException handling of Sharepoint and also posts a very simple and effective solution where he ensures the applicationdomain is treated like a singleton and circumvents tens of thousands of unneeded objects in memory.
Sasquatch-Memory Leak
http://todd-carter.com/post/2010/02/08/SharePointe28099s-Sasquatch-Memory-Leak.aspx
In his article he highlights a problem with the HttpApplicatinoException handling of Sharepoint and also posts a very simple and effective solution where he ensures the applicationdomain is treated like a singleton and circumvents tens of thousands of unneeded objects in memory.
Sasquatch-Memory Leak
Monday, March 22, 2010
Adding Rich Text from SharePoint to an Infopath Form
Problem Scenario:
You are trying to add the value from a Rich Text field from SharePoint to an Infopath form. This is a common scenario when trying to create custom Workflows in Visual Studio with Infopath Form support.
Symptoms:
Your Rich Text does not appear in the infopath form. Any text which is not marked up does not appear. Text outside of tags does appear.
Solution:
After some digging I figured that InfoPath requires the xhtml Namespace to be present for any data within a Rich Text field. After a lot of digging into XmlParsers, XMLNameSpaceManagers, XmlNameTables and the likes I found a very simple solution.
When passing the value over to the ExentedProperty in your Workflow, wrap the string with a div tag that has the xmlns='http://www.w3.org/1999/xhtml' attribute on it.
string htmlText = "<div xmlns='http://www.w3.org/1999/xhtml'>"
+ workflowProperties.Item.Title
+ "<br/>"
+ workflowProperties.Item["Body"]
+ "</div>";
TaskProperties.ExtendedProperties["Instructions"] = htmlText ;
Just one thing missing now. Infopath translates your valid xhtml and shows the actual tags. To solve this problem you will need to add some parsing to the load method of the form. Yes, that means that you will need to deploy some code with the form. But it's no biggie. Promise.
A fellow blogger has a great post on how to stop Infopath escaping the html
http://www.chrisbuchanan.ca/Blog/Lists/Posts/Post.aspx?ID=1
UPDATE!
So I thought I nailed it! Well, as long as you do not attempt to open that infopath form using infopath! As that will throw a security exception due to the underlying code. But hey! It's on the server you might say. Being hosted by Infopath Forms Server. Nobody would wanna open it in infopath anyway. Ha. Outlook 2007 does! So when your Outlook 2007 users hit the Edit this Task button, instead of getting a nice RichtText experience, they get a security error complaining about a missing digital signature.
Sorry folks. Back to the basics on this one. I'll just strip out all HTML before passing it to Infopath using Regular expressions. A nice one to achieve this is
string stripped = Regex.Replace(textBox1.Text,@"<(.|\n)*?>",string.Empty);
(found via weblogs.asp.net/rosherove/archive/2003/05/13/6963.aspx
You are trying to add the value from a Rich Text field from SharePoint to an Infopath form. This is a common scenario when trying to create custom Workflows in Visual Studio with Infopath Form support.
Symptoms:
Your Rich Text does not appear in the infopath form. Any text which is not marked up does not appear. Text outside of tags does appear.
Solution:
After some digging I figured that InfoPath requires the xhtml Namespace to be present for any data within a Rich Text field. After a lot of digging into XmlParsers, XMLNameSpaceManagers, XmlNameTables and the likes I found a very simple solution.
When passing the value over to the ExentedProperty in your Workflow, wrap the string with a div tag that has the xmlns='http://www.w3.org/1999/xhtml' attribute on it.
string htmlText = "<div xmlns='http://www.w3.org/1999/xhtml'>"
+ workflowProperties.Item.Title
+ "<br/>"
+ workflowProperties.Item["Body"]
+ "</div>";
TaskProperties.ExtendedProperties["Instructions"] = htmlText ;
Just one thing missing now. Infopath translates your valid xhtml and shows the actual tags. To solve this problem you will need to add some parsing to the load method of the form. Yes, that means that you will need to deploy some code with the form. But it's no biggie. Promise.
A fellow blogger has a great post on how to stop Infopath escaping the html
http://www.chrisbuchanan.ca/Blog/Lists/Posts/Post.aspx?ID=1
UPDATE!
So I thought I nailed it! Well, as long as you do not attempt to open that infopath form using infopath! As that will throw a security exception due to the underlying code. But hey! It's on the server you might say. Being hosted by Infopath Forms Server. Nobody would wanna open it in infopath anyway. Ha. Outlook 2007 does! So when your Outlook 2007 users hit the Edit this Task button, instead of getting a nice RichtText experience, they get a security error complaining about a missing digital signature.
Sorry folks. Back to the basics on this one. I'll just strip out all HTML before passing it to Infopath using Regular expressions. A nice one to achieve this is
string stripped = Regex.Replace(textBox1.Text,@"<(.|\n)*?>",string.Empty);
(found via weblogs.asp.net/rosherove/archive/2003/05/13/6963.aspx
Wednesday, March 3, 2010
i4i XML ruling and Office 2007
I've been getting more and more people ask me what I think about the i4i ruling which has caused Microsoft to pay hundreds of millions in damages and rework Word 2007 and Office 2010.
When I first read about it, I thought "What the heck! who does i4i think they are? The inventors of XML?" But then I read a bit more and Had a look at their patent in more detail
http://blog.seattlepi.com/microsoft/library/20090811i4icomplaint.pdf
In that patent i4i effectively claim to be the inventor of separating content from structure. Kinda what XML is all about. But then remember, the patent was issued back in 1998, when XML was still a vision and SGML was being used more heavily in the publishing industry.
So are they actually claiming to be the inventors of XML? No. Not at all. What they thought of back then effectively was a way of mapping the look and feel of a document to the data. The key here being mapping. Very similar to what xsl was designed to do.
Some info on chronological events back then in the 90s:
02 Jue 1994: i4i file a patent outlining the concept and process of splitting all formatting from the data, keeping both separate and applying a mapping mechanism to create the final output
10 February 1998: first recommendation recorded at w3.org for XML
28 July 1998: i4i patent is approved
18 August 1998: first draft specification for xsl recorded at w3.org
2003: Microsoft launches word 2003 with the ability to store tagged data in a separate area fo the document and use mapping techniques to inject the data in the desired locations on the page and apply formatting to them.
2007: Microsoft launches the new docx office document format which includes the ability to store xml data in a separate location of the file and uses mapping techniques to inject the data into the document.
So did i4i invent xml? No. they took SGML to the next level parallel to the developments in xml and xsl.
Should their patent have been approved? I guess so. It was ground breaking stuff back then and should be appreciated for its innovation. That's what innovation is all about.
Some more info from fellow bloggers:
http://milan.kupcevic.net/custom-xml-microsoft-office-word-data-store-i4i-patent-5787449-msdn/
When I first read about it, I thought "What the heck! who does i4i think they are? The inventors of XML?" But then I read a bit more and Had a look at their patent in more detail
http://blog.seattlepi.com/microsoft/library/20090811i4icomplaint.pdf
In that patent i4i effectively claim to be the inventor of separating content from structure. Kinda what XML is all about. But then remember, the patent was issued back in 1998, when XML was still a vision and SGML was being used more heavily in the publishing industry.
So are they actually claiming to be the inventors of XML? No. Not at all. What they thought of back then effectively was a way of mapping the look and feel of a document to the data. The key here being mapping. Very similar to what xsl was designed to do.
Some info on chronological events back then in the 90s:
02 Jue 1994: i4i file a patent outlining the concept and process of splitting all formatting from the data, keeping both separate and applying a mapping mechanism to create the final output
10 February 1998: first recommendation recorded at w3.org for XML
28 July 1998: i4i patent is approved
18 August 1998: first draft specification for xsl recorded at w3.org
2003: Microsoft launches word 2003 with the ability to store tagged data in a separate area fo the document and use mapping techniques to inject the data in the desired locations on the page and apply formatting to them.
2007: Microsoft launches the new docx office document format which includes the ability to store xml data in a separate location of the file and uses mapping techniques to inject the data into the document.
So did i4i invent xml? No. they took SGML to the next level parallel to the developments in xml and xsl.
Should their patent have been approved? I guess so. It was ground breaking stuff back then and should be appreciated for its innovation. That's what innovation is all about.
Some more info from fellow bloggers:
http://milan.kupcevic.net/custom-xml-microsoft-office-word-data-store-i4i-patent-5787449-msdn/
Subscribe to:
Posts (Atom)