We're working on a public-facing site that must be localized to support 70~100 languages.
Some say that you don't really want to have more than 50 variation labels in SharePoint. I can't find any backing material anywhere on the web about this.
2 Questions:
Has anyone had any experience with a deployment with a high-number of variation labels?
Has anyone read about this limitation somewhere that they can point me to?
Regards,
Peter
According to TechNet Article Plan Variationsthere is a limit of 50 varitions. However using SharePoint 2007 SP2 I have created 58 Variation Labels and managed to create the hierarchies.
Checkout Andrew Connell's book Professional SharePoint 2007 Web Content Management Development: Building Publishing Sites with Office SharePoint Server 2007
Yes, I have experiance working with a high number of Variation labels. It is not fun. Eventually we dropped use of Variations for managing our multi-lingual sites. We basiclly built a customized solution that is similar to Varitions but works the way we want it to.
Answer to number one, no, not in my experience thus far.
Info that doesn't directly answer Number 2 but may still be helpful, this is a listing of "soft limits" on various aspects of Sharepoint Services I didn't see a reference to variation labels, but there is a good amount of info there related to how much it can handle before you should see performance degradation
Found a technet article explaining this:
A variation label is an identifier that is used to name and configure a new variation site. You select one variation label as the source, which represents the site where most of the new content enters the system. The corresponding variation labels are the target labels, representing the sites to which content is copied. (Office SharePoint Server 2007 supports up to 50 labels.) You create variation sites from variation labels by using the Create Hierarchy command on the Variation Labels page of the Office SharePoint Server 2007 site administration pages.
Related
We have different business divisions and each division has its ecommerce site hosted as webpart in SharePoint 2007. We also have product/adv images/documents in SharePoint.
We want to migrate from SharePoint 2007 to SharePoint 2013 and as per our initial research we noted that we must first migrate to SharePoint 2010 and then to SharePoint 2013
Questions :
what is the best way to migrate from sharepoint 2007 to sharepoint 2013 considering above context. please provide pointers..
or should we re-write our webpart code in mvc and get rid of SharePoint. since we have soa arch i belive it would not be big pain to do so.. just ui webparts will be replace with mvc site
which third party migration tools can be used considering their reliability and cost.
please suggest best way to go ahead.
As you mentioned, there's not direct migration path from 2007 to 2013. It's hard to give a definitive answer without knowing more about your environment, it really comes down to trying to estimate the cost and time doing a manual migration (2007-->2010-->) versus purchasing a tool.
I have one customer that used Metalogix to go from 2007 to 2013 and it was fairly successful. They had a couple of branding issues and some code that had to be re-written to use updated API's but considering the scope of the migration, it was fairly smooth.
Ditching SharePoint and re-writing everything using MVC.... Not sure about that one. Even though you have a SOA architecture in place, it doesn't mean it will replace everything that SharePoint provides. It does a lot of things; security, service app scalability, branding, ECM, BCS, search, etc.
UI issue may be faced as below
Migration HTML content (in content webpart) from ntext data type to XML data.
SharePoint adds some extra tags for xml validation and it distorts to whole UI for all the pages. Means look and feel will not be as it is after migration.
Table based old structure in menus and drop-dwon is very hard to manage. It must be in and Box model for better UI management.
I had used Metalogix in my migration projects and it worked 70% fine, however be ready for the post deployment fixes as you might have to rewrite some scripts. But overall it works fairly good. I would also suggest you to run a report before migration using SPCAF tool.
I would like to find out how much space my group's SharePoint site uses (files + version history). However, I only have administrative access to my site, not the entire SharePoint instance, so I have to come up with my own solution. I'm interested in the total, but usage per individual file is also fine.
I've googled everything I could think of but couldn't find much that would help. SharePoint programming seems out of the question since I don't have access to the machine. SharePoint Web Services looked promising but none of the services provided seem to give me what I need. I also found a VBA library that lets me list the versions of a document: Office.DocumentLibraryVersion. However, this type does not include a "size" property - why not?
Anyway, I would be happy with either of the following solutions:
A library or API to be used from VBA, VB, or C# (or any other language, for that matter)
A SharePoint Web Service that provides file size/space usage information
A completely crazy script that uses http to iterate through all the folders/files/versions in the library and does insane pattern matching to figure out the size of each file, then adds them together and returns the grand total (SharePoint du)
I figured SO is the best forum for this question, but a non-programmatic solution is just as welcome. Basically, anything you can come up with would help. At this point, even "this is not possible" would be useful.
Thanks in advance.
There is a hidden page that does this... Cannot find it right now.
Check the 1033 directory and similar to /layouts/usage.aspx.
That page links to /layouts/storman.aspx. Unfortunately that page does not work if your site collection does not have a quota.
Go to Site Settings / Site Usage Report.
If what you are looking for is not there, I don't think you can do it with your level of access.
got to siote actions--> site administration-->site usage reports-->
you can get the site usgae report
if you want to get it in excel chart--> open your site in sharepoint designer-->site-->reports-->usage-->then you can get
usage summary
monthly summary
daily summary
daily page hits
etc
We have a heavily customised SharePoint publishing (WCM) site that uses no web parts in order to meet with XHTML and (AA) accessibilty guidelines. The trouble is that the search functionality is not generating any usage statistics (Usage reports within Search Administration in the SSP). We know this is down to our customisations because we have a couple of the OOTB team sites in the farm which are generating search statistics. We are not sure where/how we need to fix this. It seems we may need to wire up a call to the search.asmx web service but I'm not sure. Perhaps we need to call something from within the SharePoint API as part of our call to the search service? I'm not sure.
Has anyone out there built a heavily customised SharePoint site (no web parts) and are logging search statistics, can you comment on how you did it? Or can anyoone provide insight into how the staistics are generated?
If it helps we are running a medium sized farm with 2 WFEs, 1 Index server and 1 SQL Server box. All Windows 2003 R2 SP2, 32-Bit. MOSS 2007 SP1 (plus December CU) Enterprise Edition.
Thanks,
James.
have you checked Usage Reports in the CA-->Operations tab ?
Our (intranet) site is heavily customized and the Search Usage Reports are turned on (they should be by default). You do have to enable ALL usage reporting options though, both in the SSP as in CA, the key one being "Enable search query logging.", in the SSP -> Usage reporting. I have also found that disabling / reenabling this option will sometimes help if it is already supposed to be running.
P.S. I will vote to move this question to serverfault as that is where this question belongs.
The SharePoint search statistics is only gathered when you use the standard search webparts (SearchBoxEx, CoreResultsWebPart). This is because they use an internal hidden object to perform the searches, which, in turn, logs to the statistics. AFAIK there is no way (except possibly reflection) to write to these logs when using a custom search webpart.
We are researching the various options that exist in our environment to create an Employee Directory. We have a SharePoint portal, AD and recently moved from Lotus Notes to Exchange. Our current employee search is a custom Notes DB that has since been retired.
Since moving to SharePoint an year ago, we've used a custom list using SharePoint Profiles that are updated from AD. But the simple list interface isn't very user friendly and is very slow. Sone of the requirements include type-ahead, pictures, and details of skills/certifications and other demographic information etc. We are considering building an ASP.NET or SilverLight application that can consume the information in the SharePoint list. With the introduction of Outlook and the Global Address List, we are now wondering if it might be easier to build something within Outlook.
Has anybody traveled a similar path and what would you advice us to do?
Microsoft has a huge set of offerings for Collaboration and Social Computing in Sharepoint.
See this document, pages 8 and 9 for information about features related to an employee directory, including details of skills/certifications and other demographic information.
A la carte availability of individual features (such as People Profiles and People Search) and pricing may be an issue, but you may want to look into buying something rather than building it (if you can get the pieces you want for a price you can afford).
Sharepoint can connect with Outlook to keep the lists synchronized if you want to use outlook. And there are definitely a lot of different ways to change the way the lists are presented in the Sharepoint portal to make them more user-friendly. Having those details on the portal will certainly be a boon when combined with the powerful search and indexing features in SharePoint so you can identify employees based on their profile details easily.
We use the people search for this pretty effectively. We populate data in AD, then connect profile properties to AD attributes. That's only if you have MOSS, though. If you're working with WSS, you'll have to build something more custom.
One gotcha, though, is that the People Search out of the box doesn't easily do partial searches (i.e. searching for "john" doesn't match "johnson"). That's a big downer in my mind. You can use Ramon Scott's approach of a Content Editor Webpart with a form and some Javascript to work around it, and you can also get there via the advanced search box (albeit indirectly), but it sure would be nice if it were easy to make the default search box do partial name searches.
I recently just discoverd a somewhat easy visual basic script that draws information from the active directory where you can specify which OU to draw from where it displays all user information in a simple .HTM page. it includes a search bar, recognizes patterns (address) (company telephone number) etc... If you would like i can post it for you. you only need to fill in a few sections (display name for directory, OU, OU display, and tags) and you can always change the way things look too.
This should be taken care of by using the My Site feature that's available within SharePoint. You will then be able to search SharePoint users by skills, certifications, projects, and educational qualification.
Please refer to the SharePoint Planning and Deployment material on TechNet for more info.
SH.
Are there any blogs, guides, checklists, or controls we should be using to ensure our SharePoint implementation is accessible?
Preferrably to the W3C double A standard, or as close to that as we can get.
We're implementing an extranet solution.
This study has already been funded by Microsoft, and unfortunately the results only seem to be online in a Word Document.
The document is hosted on this blog:
http://blog.mastykarz.nl/best-practices-for-developing-accessible-web-sites-in-microsoft-office-sharepoint-server-2007/
And the path to the document is here:
http://go.microsoft.com/fwlink/?LinkId=121877
I'm unsure on whether it would be a good thing to copy the contents of that into here to fully answer the question in a way that will be indexed by search engines, but I'll play safe as it's not my content.
The best place to start is the Accessibility Kit for Sharepoint. With this, you may reach single A standard, but in my experience, you will find it very tough to reach AA.
Microsoft didn't factor in accessibility in Sharepoint, and even 2007 suffers from a huge overdependence on table layout.
Good luck!
How are you deploying the implementation? Is it as an Intranet, or, is it as a public facing website.
I think one of the first rules is to be extremely selective with the use of out of the box web parts. Many of the web-parts I looked at weren't compliant even on a basic level.
Andrew
The best way is to run checks as you develop so you know where your pain points are.
The next step maybe to start with a minimal masterpage so you can choose what elements are presented to the user.
More advanced you can override the render methods to remove or change bits of the page that are not compliant with your checks. EG changing the case of tags (XHTML does not like all caps)
A bit more in this guide.
http://techtalkpt.wordpress.com/2008/06/18/building-accessible-sharepoint-sites-part-1/
http://techtalkpt.wordpress.com/2008/08/07/building-accessible-sharepoint-sites-part-2/
I recently read the MOSS book by Andrew Connell (www.andrewconnell.com) and it has a chapter dedicated to accessibility and SharePoint sites.
Simply put SharePoint sites are very difficult to generate W3C AAA standards, but the Accessibility Kit is one of the best starting points.
Stronly recommend his book for this chapter (http://www.amazon.com/dp/0470224754?tag=andrewconnell-20&camp=14573&creative=327641&linkCode=as1&creativeASIN=0470224754&adid=18S6FKQJR5FZK56WHH6A&)
It depends how much of Sharepoint out of the box you are intending to use. In implementing our public facing site we managed to achieve AA compliance, although the amount of custom development required has raised questions over the benefits we are actually gaining from using Sharepoint in the first place.
A few pointers:
We made heavy use of SPQuery/SPSiteDataQuery to render site data to screen using xslt which gave us full control over the output. I found this link helpful:
http://blog.thekid.me.uk/archive/2007/02/25/xml-results-using-spsitedataquery-in-sharepoint.aspx
Check out RadEditor for Sharepoint for a nice accessible rich text editor for publishing.
For xhtml compliance, things were a little more tricky, we had to override most of the Sharepoint publishing controls' render methods to correct dodgy output.
If you are wanting to leverage the portal like capabilites of Sharepoint in your extranet it is more problematic. The web part framework is not accessible and I have not yet found a way to make it so. Any suggestions welcome!