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
Thursday, April 19, 2007
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
Office 14 Sneak Preview
Aero XP has posted a sneak preview on Office 14 on their site:
Office "14:" An AeroXP Exclusive
Office "14:" An AeroXP Exclusive
Thursday, February 15, 2007
Some articles about MOSS2007 navigation
Here are some articles about navigation in MOSS2007:
HOW TO: Programmatically customize site navigation in MOSS 2007
MOSS Navigation Deep-Dive - Part 1
HOW TO: Programmatically customize site navigation in MOSS 2007
MOSS Navigation Deep-Dive - Part 1
Monday, February 05, 2007
CSS Reference Chart for SharePoint 2007 (Microsoft Office SharePoint Server 2007 and Windows SharePoint Services v3)
Heather Solomon posted a CSS Reference Chart for SharePoint 2007 on here blog. This reference chart highlights the major styles used in MOSS and WSS v3 sites.
CSS Reference Chart for Sharepoint 2007
CSS Reference Chart for Sharepoint 2007
Thursday, January 18, 2007
How to change the navigation depth of the top menu in MOSS2007
The default top navigation menu shows the mavigation structure in two levels, the first level are tabs and the second level is a dropdown menu.
It is possible to change the maximum depth of these menus. To change this default setting, do the following:
The setting can be changed by changing MaximumDynamicDisplayLevels iten in the SharePoint:AspMenu tag of the master page.
- Open the default.master page at [drive]:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\GLOBAL
- Search for "TopNavigationMenu" in the file.
- Change the property MaximumDynamicDisplayLevels to the value which you like.
- Save the file and you're done.
It is possible to change the maximum depth of these menus. To change this default setting, do the following:
The setting can be changed by changing MaximumDynamicDisplayLevels iten in the SharePoint:AspMenu tag of the master page.
- Open the default.master page at [drive]:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\GLOBAL
- Search for "TopNavigationMenu" in the file.
- Change the property MaximumDynamicDisplayLevels to the value which you like.
- Save the file and you're done.
Wednesday, January 17, 2007
[SPS2003] Requesting userdetails from list item
When a user adds a new item to a list, for example an Announcement, the name of the users is registered aswell. If these items are shown on a page using a webpart, like the default Announcements on a team site, the username is shown also. It is possible to click the name of the user to request more user details.
On an environment of a customer, a "Page cannot be displayed" error message is displayed when clicking this item. After some troubleshooting and reading through the IIS log, the cause of this issue is the following:
The link of the page that displays the user details is http://<servername>/sites/<sitename>/_layouts/1033/UserDisp.aspx?ID=<id>. This aspx file requests the aspx PortalAPI.aspx. The PortalAPI request the "Up To Link" URL and tries to contact the configured portal. In our case it turned out that users configured the Up To Link to a team site instead of the portal. Therefore the PortalAPI tries to generate a non existing URL, causing the Page cannot be displayed error.
So if you run into the same issue: First check if the Up To Link is really a portal!!
On an environment of a customer, a "Page cannot be displayed" error message is displayed when clicking this item. After some troubleshooting and reading through the IIS log, the cause of this issue is the following:
The link of the page that displays the user details is http://<servername>/sites/<sitename>/_layouts/1033/UserDisp.aspx?ID=<id>. This aspx file requests the aspx PortalAPI.aspx. The PortalAPI request the "Up To Link" URL and tries to contact the configured portal. In our case it turned out that users configured the Up To Link to a team site instead of the portal. Therefore the PortalAPI tries to generate a non existing URL, causing the Page cannot be displayed error.
So if you run into the same issue: First check if the Up To Link is really a portal!!
Subscribe to:
Posts (Atom)