On an environment I have just installed I ran into an issue when I tried to start the Central Admin component on a second server. The environment consisted of two load balanced web servers and an application server. The application server had been installed first, so was running the Central Admin component. IIS had been installed on the D drive on this server.
When I tried to start the Central Admin component on one of the web servers (which only had a C partition), the component refused to start. After looking through the logs the cause turned out to be that SharePoint tried to configure the Central Admin on the D partition, because the application server also had been installed on the D partition. The only way to get around this was to create a D-partition on the web servers.
So when you are installing a SharePoint 2007 environment, make sure all partitions on all servers are the same. Or at least the drive letters.
Monday, May 14, 2007
Friday, May 11, 2007
[MOSS2007] SP1 to be released soon!!
I have just heard that SP1 is planned to be released in June/July 2007…..so quite soon.
[MOSS2007] Configure SharePoint 2007 to show the PDF icon [UPDATED]
To configure SharePoint 2007 to show the PDF icons with PDF documents, do the following:
PDF Icon:
- Download the pdf icon.
- Copy the image to C:\Program Files\Common Files\Microsoft Shared\Web server extensions\12\Template\Images
- Edit the docicon.xml in C:\Program Files\Common Files\Microsoft Shared\Web server extensions\12\Template\XML and add: <Mapping Key="pdf" Value="icpdf.gif" />
- Perform an IISReset.
- Voila, you are done!!
PDF Icon:
[MOSS2007] Missing “Up” button in folder
I have just ran into the following issue:
When you open a document library which contains folder, the breadcrumb trail above the document library enables you to go back up into the folder structure. But when you show this library on a SharePoint page using a webpart, after going into the folder the only way to get back up is to use the “Back” button of your browser. In SharePoint 2003 the toolbar showed an “Up” button, but this button seems to have disappeared in SharePoint 2007.
Also when you apply one of the other masterpages which are supplied out-of-the-box (for example, BlueBand.Master) the breadcrumb trail which works in the default masterpage seems to break as well.
I think this might be an issue to be fixed in SP1 :-)
When you open a document library which contains folder, the breadcrumb trail above the document library enables you to go back up into the folder structure. But when you show this library on a SharePoint page using a webpart, after going into the folder the only way to get back up is to use the “Back” button of your browser. In SharePoint 2003 the toolbar showed an “Up” button, but this button seems to have disappeared in SharePoint 2007.
Also when you apply one of the other masterpages which are supplied out-of-the-box (for example, BlueBand.Master) the breadcrumb trail which works in the default masterpage seems to break as well.
I think this might be an issue to be fixed in SP1 :-)
Tuesday, May 08, 2007
[MOSS2007] PDF and SharePoint 2007
Just like in SharePoint 2003, SharePoint 2007 does not show the pdf icon and is not able to index these files. But fortunately Microsoft made it possible to reconfigure SharePoint yourself and upload an icon and install a PDF iFilter. Adobe created an iFilter to accomplish this.
SharePoint 2003 only came as a 32-bit version, but with SharePoint 2007 SharePoint can be installed as a 64-bit version as well. And here is the catch……Adobe has not released a 64-bit version of its iFilter yet and it looks like it won’t be available for a very long time (come on Adobe!!).
To solve this issue you have several options:
So go ahead and download the 32-bit version or the 64-bit version
Happy indexing!!
SharePoint 2003 only came as a 32-bit version, but with SharePoint 2007 SharePoint can be installed as a 64-bit version as well. And here is the catch……Adobe has not released a 64-bit version of its iFilter yet and it looks like it won’t be available for a very long time (come on Adobe!!).
To solve this issue you have several options:
- Reinstall the server with 32-bit Windows and reinstall SharePoint…….ok, not really an option.
- Not index PDF files at all…….ok, also not an option.
- Beg Adobe to create a 64-bit version of their iFilter…….ok, you have something to do for about 5 minutes but it won’t solve your problem. But if you have nothing to do……go ahead: Submit Product Enhancement
- Try to trick MOSS into accepting the 32-bit version of the iFilter…….uhm, do you really want to?
So go ahead and download the 32-bit version or the 64-bit version
Happy indexing!!
Thursday, April 19, 2007
Error when trying to create a crawl schedule for a content source
When you try to configure a crawl schedule for a content source, you will receive the error message:
Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)
This is a known issue and Microsoft has published a solution on their site: KB926959
Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)
This is a known issue and Microsoft has published a solution on their site: KB926959
Monday, March 19, 2007
Language Packs and Microsoft Office Sharepoint Server 2007
MOSS Language packs enable site owners and site collection administrators to create SharePoint sites and site collections in multiple languages without requiring separate installations of Microsoft Office SharePoint Server 2007. You install language packs, which contain language-specific site templates, on your front-end Web servers. When an administrator creates a site or a site collection based on a language-specific site template, the text that appears on the site or the site collection is displayed in the site template's language. Language Packs are typically used in multinational deployments where a single server farm supports people in different locations or in situations where sites and Web pages must be duplicated in one or more languages. Application of a Language Pack will not change the language of the installed Office server product SKU.
- What’s the difference between WSS Language Packs and MOSS language Packs?
- WSS Language Packs are for WSS stand-alone installations and enable the creation of SharePoint sites in different languages; multiple language packs can be installed on the same server.
- MOSS Language Packs are for MOSS, MOSS for Search, Forms Server, and Project Server installations and enable the creation of SharePoint sites in different languages; multiple language packs can be installed on the same server.
What’s the difference between a MOSS Language Pack and a fully localized version of MOSS?
Microsoft’s 2007 Office server products are localized into languages in two different ways:
- fully translated SKUs and
- Language Packs.
A language-specific SKU delivers the respective Office server product localized into a given language. A Language Pack may be applied to an installed Office server product to create sites or site collections in other languages. Application of a Language Pack will not change the language of the installed Office server product SKU, or the language of the admin features.
How does a customer license them?
MOSS Language Packs can be downloaded and installed on Microsoft Office SharePoint Server 2007 servers free of charge. If the Language Packs deployed fall within your “listed languages” then your Microsoft Office SharePoint Server 2007 Standard and Enterprise CALs license your desktops/devices for those Language Packs. If Language Packs deployed fall outside of your “listed languages” then you will need to consider modifying your CAL to a multi-language option (for Select/Open agreements) or an “all languages” option (for Enterprise Agreements).
What’s the pricing?
There is no cost for MOSS Language Packs; however, there may be additional CAL costs associated with licensing for languages outside your listed languages.
More information about deploying MOSS Language Packs can be found at the Microsoft TechNet site. The following TechNet articles relate to MOSS Language Pack deployment:
I heard that there are issues related to specific server language packs. What is this about?
For certain languages (Arabic, Hindi and Thai), spellers were not included in either the fully localized version of MOSS or the MOSS Language Pack. (Spellers for Basque and Galician are also absent from the Spanish MOSS and Spanish MOSS Language Pack). These spellers, as well as instructions for installing them, will be made available to customers via the MOSS Server Multi-Language Pack (SMLP). The SMLP will be downloadable from the Microsoft Download Center and MVLS/eOpen web sites. The SMLP is expected to be available towards the end of May 2007. Note: while a customer can obtain any MOSS Language Pack or the SMLP free of charge, they are not necessarily licensed to use all of the languages. They should consult their listed languages for more clarification on which languages they are licensed to use.
More information about language pack availability: Estimated release timeframes for SharePoint 2007 Language Packs
(Source: Additional information about WSS 3.0 and MOSS 2007 Language Packs)
Thursday, March 01, 2007
Search and Index Sizing and Planning - Real world data from MSW
Source: Blog Joel Oleson
"I've heard such a huge variety of guidance around Index sizing. This is a topic that will have a huge swath, so its very important to understand your data or to be conservative. If you have the ability to resize later or add larger disks you may find this data compelling.
In the capacity planning document you'll see we recommend 30% of disk for Index. What does that mean? Well, since now we have a search db, the index edb file, and SSP database it can be confusing. Reading the response from Sam from Microsoft's internal/Intranet deployment you can see how mileage really does vary. If the 12TB deployment which is currently being indexed were to have 30% of disk just for the size of the index on disk, the file would be 3TB! Currently the index file on disk is 83GB, but the search database is 243GB. This is with 19.4 million documents indexed. Since the recommendation is to have 2X the size for the index file for swapping it out on the query server, a planner would say that they should plan for 60% on disk or over 6TB. This would be quite a loss given the current size or "real world" size is 83GB. They currently have 300GB allocated for that drive and since it's on a SAN they can grow the disk if needed. Obviously with a heavy records management repository or a page heavy site will have different results, so be sure to understand your content.
My tip is don't over plan or let this kill your design on this one. The recommendation has gone from 50% to 30% over time, maybe you've even seen 10%. My recommendation is to understand your data. Remember that the content of audio, video, archives, ZIPs, PDFs, MDB, MPP, MSG, VSD, GIF, JPG, PSD, CAD, WAV, MSI, EXE, and hundreds of file types are not indexed by default. You have to add Ifilters for the files that are not indexed by default (which is a pretty decent list (most Office file types and text based formats) and you should be selective about what you add since many of them are not multi threaded. The other consideration is file size. If files larger than 16MB are not indexed by default, then the biggest files taking up the largest size on disk won't be indexed. When you have a 15MB PPT, how much of it is even indexed? Maybe 100K worth (if you have verbose notes)?
Our indexes are larger than they were in SPS 2003, but my recommendation is to be conservative at 10% with the expectation that you'll really see something around 1-5%. Don't underestimate the Search Database though. In the MSW farm, that database sees the most action in terms of writes. It is the most actively written to database in the farm from what I hear. Makes sense understanding that it is the property store. Although I've almost completely gone to RAID 5 in all my planning for minimizing cost, I do recommend a RAID 0+1 drive for the search and config database, and RAID 0+1 for the transaction logs.
Message from Sam...
The real-world data today is that we are indexing 12TB of Sharepoint content worldwide + an unknown amount of non-Sharepoint content from our Redmond SSP. The numbers look like this:
Number of documents indexed: 19.4 million Size of search database: 243GB Size of index on disk: 83GB
Thus you could consider the amount of disk used to be about 326GB. Assuming a 14TB total corpus say (just a guess, really) then the real-world data would indicate 2.33%. Of course this is very much a 'mileage may vary' exercise as everyone's document mix is different."
"I've heard such a huge variety of guidance around Index sizing. This is a topic that will have a huge swath, so its very important to understand your data or to be conservative. If you have the ability to resize later or add larger disks you may find this data compelling.
In the capacity planning document you'll see we recommend 30% of disk for Index. What does that mean? Well, since now we have a search db, the index edb file, and SSP database it can be confusing. Reading the response from Sam from Microsoft's internal/Intranet deployment you can see how mileage really does vary. If the 12TB deployment which is currently being indexed were to have 30% of disk just for the size of the index on disk, the file would be 3TB! Currently the index file on disk is 83GB, but the search database is 243GB. This is with 19.4 million documents indexed. Since the recommendation is to have 2X the size for the index file for swapping it out on the query server, a planner would say that they should plan for 60% on disk or over 6TB. This would be quite a loss given the current size or "real world" size is 83GB. They currently have 300GB allocated for that drive and since it's on a SAN they can grow the disk if needed. Obviously with a heavy records management repository or a page heavy site will have different results, so be sure to understand your content.
My tip is don't over plan or let this kill your design on this one. The recommendation has gone from 50% to 30% over time, maybe you've even seen 10%. My recommendation is to understand your data. Remember that the content of audio, video, archives, ZIPs, PDFs, MDB, MPP, MSG, VSD, GIF, JPG, PSD, CAD, WAV, MSI, EXE, and hundreds of file types are not indexed by default. You have to add Ifilters for the files that are not indexed by default (which is a pretty decent list (most Office file types and text based formats) and you should be selective about what you add since many of them are not multi threaded. The other consideration is file size. If files larger than 16MB are not indexed by default, then the biggest files taking up the largest size on disk won't be indexed. When you have a 15MB PPT, how much of it is even indexed? Maybe 100K worth (if you have verbose notes)?
Our indexes are larger than they were in SPS 2003, but my recommendation is to be conservative at 10% with the expectation that you'll really see something around 1-5%. Don't underestimate the Search Database though. In the MSW farm, that database sees the most action in terms of writes. It is the most actively written to database in the farm from what I hear. Makes sense understanding that it is the property store. Although I've almost completely gone to RAID 5 in all my planning for minimizing cost, I do recommend a RAID 0+1 drive for the search and config database, and RAID 0+1 for the transaction logs.
Message from Sam...
The real-world data today is that we are indexing 12TB of Sharepoint content worldwide + an unknown amount of non-Sharepoint content from our Redmond SSP. The numbers look like this:
Number of documents indexed: 19.4 million Size of search database: 243GB Size of index on disk: 83GB
Thus you could consider the amount of disk used to be about 326GB. Assuming a 14TB total corpus say (just a guess, really) then the real-world data would indicate 2.33%. Of course this is very much a 'mileage may vary' exercise as everyone's document mix is different."
Friday, February 23, 2007
The "Fantastic 40" are complete
Microsoft has released the remaining 20 templates of the "Fantastic 40". The first 20 were named "Site Admin Templates" and the last 20 are named "Server Admin Templates". More information can be found at New Application Templates for Windows SharePoint Services 3.0 or at Completing the "Fantastic 40" – 20 remaining application templates now available, plus more!
Microsoft SQL Server 2005 SP2 Reporting Services integration with WSS 3.0 and MOSS 2007
A few days ago Microsoft released Service Pack 2 for SQL Server 2005. This Service Pack enables deep integration with Microsoft Office Sharepoint Server 2007 (MOSS2007) and Windows SharePoint Services v3 (WSSv3).
On the blog of the Microsoft SharePoint Products and Technologies Team a new post describes the ins and outs of this integration:
Microsoft SQL Server 2005 SP2 Reporting Services integration with WSS 3.0 and MOSS 2007
On the blog of the Microsoft SharePoint Products and Technologies Team a new post describes the ins and outs of this integration:
Microsoft SQL Server 2005 SP2 Reporting Services integration with WSS 3.0 and MOSS 2007
Subscribe to:
Posts (Atom)