Tag Info

Hot answers tagged

8

Subsites are incredibly useful in all the following scenarios This site has a different function from the main site. Assuming you are talking about an internal portal, generally you would want your helpdesk and your social committees to have their own subsite each. Because their information will almost never be relevant to each other, and they are both ...


8

SharePoint is a platform that provides business services. Some applications will integrate well with the platform, some won't. Here are some of the questions you should be asking yourself: Can we incorporate SharePoint OOB functionality to reduce over all development time? Are SharePoint lists and libraries a suitable data store for this application? Can ...


8

I'd go for the SQL database. For several reasons: Storing into SharePoint list adds a lot of overhead that you don't need. With 20K items per day you'll reach the supported max in 15000 days and list throtling limit in 6 hours But most important with that amount of data what you want to get out is aggregate to make sense of the data. And this is the area ...


5

If they are looking to add 10m items per year and retain content for 2-5 years, then I would probably design the initial system to support 30m items and grow it as needed in 2-3 years. Business and technology changes may require a different topology at that point. One Crawl Server / Index Partition can support up to 10m items. In many cases you will want ...


5

I use layered architecture in all my SharePoint solutions and treat SharePoint generally as the UI layer, keeping it very thin. Any logic goes into the business model and I have DAL wrappers to abstract away the List infrastructure (which also helps with testing). For a good read on layered architecture in ASP.NET check out this article here. It's ASP.NET ...


5

Using API, you won't have any limitation on what you can done. Using Web Services you will be able to do a lot of things, but mainly concerning structure and/or data query Using Rest services, you will only be able to perform CRUD operation. It actually depends on you requirements. There is also a 4th way, that requires a bit of more work : use the OOB ...


5

I would, and have in the past, use a separate SQL database to store all of that data. This will require additional work for the presentation of the data, but using BCS, SSRS and/or PowerPivot, you can pretty easily pull that into SharePoint. I wouldn't put that much into a SP content database and expect good things ;)


4

How would rssbus help? Does it replicate between SharePoint Lists and normalized databases? Why not spin up SP2010 farm now and leverage BCS now? Be careful as normalized db's means most likely custom BDC model in Visual Studio 2010 to manage the mapping. Also BCS External Content Type List doesn't support everything a standard list does.


4

I think the main driver is that a lot of core things that would take custom development can easily be created out of the box with SharePoint. In theory, you should have less development cycles since the only place you have to "develop" is the custom extras that you may (or may not) need. You also have the added benefit of your LOB tools being directly linked ...


3

Your performance and redundancy requirements translate into an appropriate disk configuration. e.g. If it's a really busy server and you require maximum redundancy, you might choose to separate out file types logically into RAID 10 volumes. In my fairly limited experience this is normally considered overkill except in the case of SQL server. In that case, ...


3

TMS included the Business Data Connector (BDC) and Burliness Connectivity Services (BCS) to assist with such scenarios. Some good overview: http://technet.microsoft.com/en-us/library/ee661740.aspx http://www.lightningtools.com/bcs/Business-Connectivity-Services-Introduction.aspx Coincidentally (not really) lightingtools make some cool BDC/BCS tools for ...


3

The SPWebService is a container for the SPWebApplications. For instance You can use the SPWebService.ContentService static property to return the SPWebService object which contains all content web applications (the SPWebService.AdministrationService can be used to get the web app for CA).


3

Agree with Bil. Web parts, web controls, application pages etc should only be the UI layer that calls into a layer that is agnostic of the original calling context; calling context could be an event receiver, console application, timer job, workflow, etc. Always ensure that this shared layer you call into does not have a dependency on SPContext.Current ...


3

SSRS, to be used in SharePoint Integrated Mode, must be installed on a server that has SharePoint installed and joined to the farm. Obviously this would not be a good idea to install SharePoint on a Database Engine server if you can avoid it. Install SSRS on your SharePoint server in Integrated mode. Yes, you must license SQL Server (SSRS) on your ...


3

As far as I know or according to my experience you should be creating Site Collections for departments and let each department have there own content database as a best practice. Web applications should be created on the basis of mode of authentication. I would recommend you to go through these topology diagrams provided by Microsoft to understand the ...


3

•Query server. A query server hosts query components and index partitions Query components return search results. Each query component is part of an index partition, which is associated with a specific property database that contains metadata associated with a specific set of crawled content. You can make an index partition redundant by ...


3

Query Server == Application Server. A "query server" is an application server with only the search service (in this case the query role) role enabled. You could also have a "Access Server" if you would only enable the Access Services role on the server because you have large loads of Access documents being processed. The query server and the search index ...


2

Well you could mix various Windows version as long as they are using same architecture (32/64bit). But I would recommend an upgrade to 2008 because of following: to ease and uniform patching of your systems SharePoint 2010 will only support Windows 2008, it will be easier to upgrade if you are running 2008 already


2

This is a very good question. In the past I have worked on these kind of systems in combination with SharePoint. What we did was the following: Use SharePoint as the front end. Leverage Web Parts, Event Receivers, workflows, deployment, uploading of files and user security. Don't store any transactional data in SharePoint. It just doesn't scale well, ...


2

The Service Applications are redundant if you make sure that you install and start the services on multiple load balanced application servers. SharePoint 2010 handles the load balancing for you. Regarding the fail-over strategies you have to look into the different services and if they use a database for storage or not. The databases that the SA uses must ...


2

Balsamiq has a good set of tools and is one of the favorites for some SharePoint designs. Clever Workarounds has a nice review of the tools specifically for using them with SharePoint. There are two pre-built templates that I know of you can use with Balsamiq and SharePoint. This one is for 2007 sites and this one is for 2010. Hope that helps!


2

Here are some popular blog posts I wrote in the past: SharePoint Site Topology Planning Site Topology Planing and Taxonomies I believe they are still helpful and relevant.


2

Your database server "can" serve multiple SharePoint environments, either by creating unique database names between environments, or by creating a separate SQL instance for each environment. Just because you can obviously doesn't mean you should... your requirements would dictate if that's a viable option. As for the SharePoint end of things. To my ...


2

It may come as a surprise to you (which only shows how little it has been written about this) but most of the ‘important’ things in SharePoint are actually done through unmanaged code and the SharePoint .NET object model provided by the Microsoft.SharePoint.dll is a sort of a wrapper to this unmanaged world. Understanding how your code does what ...


2

The only reason to use Office 64 bit is if you're working with HUGE documents (usually excel or access) which are to big to losd in the 32 bit version. Otherwise you should always use 32 bit as there are several peices of functionallity which isn't implemented in the 64 bit version, especially around the browser plugins which SharePoint takes advantage of. ...


2

Refer to the SharePoint Guidance from patterns & practices They have a section on configuration data which would apply, and part of that section includes storing configuration data in a list. The list implementation is much like a hashtable.


2

The answer to your question is certainly not a straight forward one as there are multitude of things that implicates whatever is mentioned below. However the points mentioned below will get you a head start on seeing what you can call a "holistic view" of the sharepoint technology itself and how fits within any organization thereby you understand where does ...


2

I just started out with SharePoint in May and I read through the 'Microsoft SharePoint 2010 Unleashed' book (http://www.amazon.com/Microsoft-SharePoint-2010-Unleashed-Michael/dp/0672333252) and 'Real World SharePoint 2010' (http://www.amazon.com/Real-World-SharePoint-2010-Indispensable/dp/0470597135) although I went through the first one a lot more ...


2

I don't think you can do this directly in SharePoint, however you may be able to configure IIS or you could use a load balancer to achieve this. IIS: - If you set each Web Application to use it's own app pool then you could use the app pool advanced settings to set the processor affinity or limit the max percent of cpu usage. You can also specify a max ...



Only top voted, non community-wiki answers of a minimum length are eligible