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 ...


6

Although the answer to your question does have a variety of different perspectives that can blend together to come up with a "one shot" coverage scope for a SharePoint Architect but I think it is better if we look into a SharePoint Architect as a mix of different architectural backgrounds working under a single umbrella in a more agile manner. Primarily , ...


6

IT architecture is something you mature into with experience. Just focus on developing good solutions, and build those skills. Always take opportunities to work on projects that cover different areas - for example, if you've built lots of web parts, work on a project that uses BCS or InfoPath, or Excel Services. Always pay attention to the hardware & ...


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

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 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 ...


4

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

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

I'll second what James said and add to it. With 2010, authentication methods aren't as important a consideration because you can have multiple authentication types associated with a single web app through Claims Based Authentication. Security may still be a consideration when splitting out your web apps and site collections though. The department sites, ...


3

There are quite a few ways to increase sharepoint peformance like External binary store and Remote blob store (SharePoint 2010). There are some third party solutions available like NCachePoint, StoragePoint which provide these features. A good thing abount NCachePoint (http://www.alachisoft.com/ncachepoint/index.html) though is that it has some nice ...


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

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

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

•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 ...


3

Is it the front/app servers we are concerned about, or is it the SQL? You could create a farm where all roles (web app, application, crawl, index) are distributed to at least 2 servers (and where SQL is mirrored on two servers). I'm not sure about "within seconds", but if you configure mirroring correctly the SharePoint databases will know of the ...


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

The main defining point in whether to separate out web applications is (well, was in 2007, that's probably changed in 2010) authentication methods - are my users all internal on AD or are there a bunch gonna be authenticating via FBA, and that kinda stuff. Site collections separation is down to permissions requirements really. I guess it depends on every ...


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

I did exactly as you suggested and it worked in my test environment. So I guess you have the right approach. It was not production so you should check with your user before making any changes. I hope this helps :)


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

If you're looking for an off-the-shelf solution, although I haven't used it myself I'm also pretty impressed with what Aptimize does. It performs a series of tweaks such as JS minification, generating image sprites, merging CSS files etc. to reduce the payload of the page. Microsoft use it on sharepoint.microsoft.com, see How we did it: Speeding up ...



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