I currently have SharePoint Foundations 2010 set up in our network. I have been directed to bring up SharePoint Foundations 2013 for a separate project. We would then slowly migrate all data to SharePoint 2013. Is it possible to have two completely separate SharePoint instances in one domain? Assuming of course that they would each be on their own front end server and sql database servers.
Yes, you can have any number of instances of SharePoint in the same domain. It will not be an issue.
JD
Yes, you can have two instances of SharePoint, but the urls need to be slightly different, just as the servers need to have different names.
That's not a bad strategy for upgrading if you don't have gobs of content that would have to be moved over right away.
Here's an example, if your domain is xyz.com and your first sharepoint server uses xyz.com, you could set your second instance up as sharepoint.xyz.com
You would just need to make sure you had dns set up to point sharepoint.xyz.com to your second server's ip address.
Related
I'm a sharepoint newbie and I'm on the installation phase.
My question is:
Can 2 sharepoint servers (different versions & running on separate machines) point to the same configuration database?
Thanks in advance!
No.
Several SharePoint servers within the same farm (which is an logical concept in SharePoint) do need to point to the same configuration database. However, in your case where you have 2 different versions (I assume you're talking SharePoint 2010 and 2013), that will not work as there are differences in the configuration databases between the two versions.
It is totally okay though to host multiple configuration databases on the same SQL server if you want.
I am building a publicly facing website that does the following.
Users log in.
And then view a list of their customers.
They click on a customer to view their past purchases, order them, change them etc.
This is not a shopping site by the way.
It is a simple look up tool.
Note that none of the data accessed by the website is in anything other than a SQL database - no office documents. Also, the login does not use users Windows credentials on a VPN or something like that.
Typically I would build this using a standard ASP.NET MVC website.
However the client says they want to use Sharepoint.
As I understand it, Sharepoint is used for workflow and websites that are collaboration tools such as the components you can see here http://www.sharepointhosting.com/sharepoint-features.html
Here are my questions:
Would I be right in saying that WSS is completely inappropriate for this task as it comes with an overhead that provides no benefits?
If I had to use it, would I need WSS or MOSS?
If I had to use it, would I be right in saying the site would consist of :
List item
a) Web Parts
b) And a custom site layout. How do I create one of these?
Addendum:The book Professional SharePoint 2007 Web Content Management Development looks like a good start
1.) I agree that SharePoint would be quite inappropriate for this task. A few reasons:
It costs thousands of dollars to license SharePoint for use on the open Internet
SharePoint will use a lot of resources (SQL Server, IIS, Active Directory...) that are unnecessarily demanding for your task
SP will give you very little flexibility to develop a solution in your way -- it sounds like you would need to create a database-connected Web Part in ASP.NET anyway (so that could be entirely independent of SP)
SharePoint has it's place--it can be remarkably helpful as a company's internal document management, intranet, and workflow/approval system--but it is not well suited for custom code nor Internet use.
2.) I believe MOSS would be required for the Internet license (as in the link above).
3.) SP development is not like typical relation database systems (for example, it uses flat, unnormalized tables). If your SQL matched the SharePoint way of thinking, you might be able to connect to your database as an external List using SharePoint Designer. More likely you would need to use Visual Studio to create a custom Web Part in ASP.NET.
Hopefully this'll be a few reasonable arguments you can use to help the customer see how SharePoint is inappropriate for the task... In fact, I expect just the first point (the cost of licensing) will turn them.
You can technically use WSS for this task but MOSS has more features aimed at building public facing websites. The publishing infrastructure comes to mind. It has has the CQWP which enables you to build custom interfaces which perform well in SharePoint. With SharePoint there are potentially challenges around scalability. If you know the platform well then doing something like what you have suggested would be a pretty quick task. If you don't know SharePoint and the underlying system well you could face challenges.
You do not want to approach building the final application with SharePoint Designer. It has behavior which can cause major problems with scalability. You want to create a SharePoint Solution comprising a number of features which can be easily deployed to SharePoint. Going this route does not alleviate performance problems but you are going to be closer to the right solution. You can package up the custom user interface elements as CQWPs or write Web Parts. I personally prefer to write Web Parts.
You do the overall site design in a Master Page. Pages within a site are then inheriting from this. If you have MOSS then you can create what are called publishing pages which contain your Web Parts. These are not available in WSS which is why people recommend against it for public websites.
To decide whether SharePoint (any version) is worth it, you need to find out if they are going to use any of the core features. If everything is going to be custom and you are not going to make use of any workflow or document management features in your deployment then I would stay away. To see whether you want to go further with SharePoint from a development perspective, take a look at the WSS developer labs. I recently ran an intro course at my employer using the materials from that site. They are dated, and need more info on best practices but they provide a quick way for you to dip a toe in the water and decide whether you want to go any further.
1) For the core functionality as you describe it SharePoint isn't going to add anything, BUT if you build it on SharePoints premisses it allows your client to add a lot of functionality outside the core for "free" like:
They can add Content Editor WebParts to pages where they can add descriptions, and messages
They can add lists where the customers can enter requests/comments/... and automatically have new entries mailed to anyone in the organisation subscribing to changes
The functionality you develop can be reused on their intranet
Any future small "web apps" can be included in the same site
...
So all in all unless you have a better framework to use then use SharePoint
2) WSS is all you need for now
3) Your main deliverable for now would be:
a feature with some Site Pages and a few Web Parts
a feature with a custom masterpage and corresponding css
True. Well not inappropriate but it doesn't add anything either.. but maybe in the future?
WSS is enough
You'd need web parts to expose your data, yes. The custom site layout is not necessary. If you want your own look and feel a SharePoint Theme may suffice. Even if you want some real custom layout tweaks you probably don't need a site template but you can get away with using just SharePoint Designer to edit the pages or master page.
I need to migrate our SharePoint farm to a new domain. Until everything is moved we have full trust set up between the domains.
Farm Hardware
One WFE/Index Server
Two SQL DB Servers (clustered)
I know how to do this using all new hardware from production to a dev environment but doing an in place migration seems more daunting. To take some of the pressure off we have a new beefy SharePoint box to install to that will be a fresh box on the new domain but we don't have enough hardware to have a separate SQL cluster.
I am told that all the boxes should be on the same domain so now the hard part is to bring the SQL box on the new domain. Can I just switch domains on the SQL DB cluster and then install SP on the new WFE?
Voted to move to serverfault, but here's my 2 cents. Moving SQL Server 2 a new domain is easy, sql server will pick up any changes. The problem is sharepoint. SharePoint users to be exact.
Any documents in your site(s) will have it's created by / modified by broken, because even though the same users exist in the new domain, the bindings will be incorrect, sharepoint expects for instance user userA#olddomain.local, which is very different from user userA#newdomain.local. There is a way around this using httpmodules etc, but it is a pain in the ass.
Check out the result when googling migrate sharepoint new domain.
I've run a similar setup before. If they're full trust, you should be able to reconnect to your pre-existing config/content dbs from the new SharePoint instance in the new domain.
SQL server
You can have your SQL server in a different domain as long as there is a trust between the domains.
Migrating users
With regards to migrating your users, it's a daunting task because those user's SIDS own objects, I've used stsadm -o migrateuser but it's not terribly helpful, I'd consider looking into 3rd party software such as DocAve who have products that assist in migrating SharePoint content. If you really want to hack it, break open the Users table in your content databases and write a script to update the usernames and sids.
I want to use a CMS that can be accessed by my clients via the internet. All SharePoint usage I have seen is for intranet sites only. What I am looking to do:
Landing page for all clients, with general information.
Client login to client specific portal page with client specific information.
Accessible via the internet. The clients may or may not have SharePoint.
General and client specific wikis.
I won't be hosting this myself. I would be looking for a hosting provider as well.
I am also looking at using DotNetNuke, which has a lower cost of entry. I am open to suggestions of other CMSs, but my skills are built around C# and ASP.NET.
Before going down the SharePoint path, I wanted to make sure these things are possible.
Thanks!
Update:
Thanks to all that have given me some points to ponder. In summary, here is what I have decided to do (given my current skill set):
SharePoint can be used for my needs (my initial question). Many great example sites.
DotNetNuke as my CMS. I realize other good CMSs are available, but I prefer to stick to the Microsoft stack.
Branding will be easier in DotNetNuke.
The site will not be very big and not used by many. SharePoint will be overkill at this point.
Many of the 'modules' I am looking to use (wiki, forum, ...) seem to have more options/maturity using DotNetNuke.
Biggest Deciding Factor
Integrating a CMS solution with my software product and then installing/implementing this solution for individual clients will have a much larger cost with SharePoint. DotNetNuke will allow me to 'leave behind' the solution with the client without having them to invest heavily in SharePoint if they do not already own it.
Thanks to all!
Ed
Everything you require is supported by Windows SharePoint Services 3.0, which is included at no additional cost with a Windows Server license. However, SharePoint does have an administrative and development overhead that you could avoid using a different platform. It doesn't sound like you would really be leveraging any of SharePoint's particular strengths (document management, Office client integration, ad hoc collaboration sites, etc), so it's probably not worth the extra effort.
So in short, the answer to your question is "Yes", but it's probably not your best option with these specific requirements.
Check out the Top 17 case studies for Microsoft Office SharePoint Server 2007 and several new MOSS-based web sites. There are some nice Internet websites too.
there are heaps of SharePoint sites out there facing the internet. There’s a great list of over 1,000 of them on the WSS Demo site here: http://www.wssdemo.com/Pages/websites.aspx
All of the requirements you’ve listed are achievable with the externally facing SharePoint model. There’s an obvious cost impact of going down the SharePoint path versus DotNetNuke but it’s certainly achievable in terms of functionality.
Kentico offers SharePoint Connector which allows to publish SharePoint content to external sites: http://www.kentico.com/cms-asp-net-features/sharepoint.aspx
All the things you mentioned are possible. Note that hosting a SharePoint server can be expensive. Most hosting providers charge you a dedicated server hosting plan.
Also I'm not impressed with the default wiki solution in SharePoint. You might want to consider a 3th party wiki tool and point your SharePoint Search towards it so that the results are shown in your search results. Drawback is that you loose the security trimming.
You might also be interested in the BPOS solution. A (kind of) hosting service for SharePoint that Microsoft is offering.
I'm currently planning the migration of a Microsoft Content Management Server (MCMS) website to a SharePoint 2007 publishing site.
The top-level site is a public facing, anonymously-accessible website. It will contain two areas which need to be protected with forms-based authentication - each of which will have a distinct set of users.
There is content in the current MCMS site which uses "Connected Postings", which is the ability to use content in multiple places without duplicating it. In SharePoint, a similar concept is supported via the Reusable Content list, but this doesn't span site collections.
I'm thinking that this should be a single web application with three site collections. 1 for the public facing site, and the others for the two protected areas. However, I'm not sure if 1 site collection can be anonymous, with the other 2 implementing different FBA authentication providers.
I'd like my Urls to be something like:
www.whatever.com
www.whatever.com/protectedarea1
www.whatever.com/protectedarea2
Without Url rewriting, this would be difficult to do with separate web applications.
If I end up having to go with 3 separate web applications in order to get authentication to work as desired, I will probably have to get creative with content deployment so as not to duplicate content during authoring.
Would appreciate any thoughts, thank you!
Don't do MCMS so cannot answer specific to that, see http://www.andrewconnell.com/blog/ for alot of info.
Microsoft has a bunch of different designs for extranets, http://technet.microsoft.com/en-us/library/cc263513.aspx depending on your needs. You can set it up as you are describing, forms are a little weak put their is some a better version available on CodePlex.
For the URLS, Sharepoint has a feature called "Manged Paths" that will do what you want. No URL rewriting needed.
Our setup is a site collection for extranet and internal, where most work is done. When finished they can publish it(does make an extra copy) to the public site. Some public sites are publish only sites where they have no interaction with non-account people, some are sites were they actually do most of their work and non-account people can make contributions. All are available under MOSS.
Thanks, that extranet link will be helpful when looking at separating the authoring environment from the publishing environment.
I was trying to implement two FBA membership providers on two site collections within the same web application. Doesn't look like I can do that, gonna try using the same membership provider with different roles.