Why do I need to create Multiple SSPs in MOSS?
My manager (sharepoint administrator) asked me to create another SSP which he wanted to use for TOP Management users. He didnt tell me what was the reason for it.
I was wondering what all scenarios we need to create Multiple SSPs. Any ideas?
Very vague question, please add more info!
And as a general answer, you don't need to, the concept is to share the services under the SSP between multiple web applications, what scenario do you have to need to create more than one?
Edit after question update:
An SSP host the services that will be used ( consumed ) by any associated Web applications. These services include :
Profiles
Audiences
Business Data Catalog Connections
Search and Indexing
Single Sign On
Excel Services
Usage Reporting
Source
So if your manager won't actually have something special on any of those services, I don't see a reason to do it. We had a customer once that needed the entire mysite and profiles customized, so we created a SSP just for that one web application.
Related
I'm a developer that wishes to have a landlord site which manages tenants via Orchard. I've Enabled the Orchard.MultiTenancy module, started using it and created multiple sites for my purposes.
However, I'm still somewhat in favor of coding stuff and not just edit it via a high-level Orchard user.
Trying to find each tenant's MVC site wasn't successful.
Any suggestions ?
If one tenant crashes, does it take with it all the other tenants (since I can't seem to find an Application Domain for each)?
The whole point of multi-tenancy is to increase site density by letting multiple Orchard sites live in a single IIS application. There is not one site per tenant. The tenants are only separated in the DB, but all share the same files.
If a tenant crashes, well, it depends on the crash. Most exceptions won't even take out the tenant.
I'm currently investigating the possibility of my company using Azure.
Our current hosting situation that we run ourselves involves a separate site in IIS for each of our clients, each one having a virtual directory to the CMS we've built with ASP.Net web forms. We can update the contents of that virtual directory, which then provides the latest version of our CMS to all our clients at once.
I'm not looking to recreate that exact situation in Azure, but I am instead interested in figuring out how to create a single Web application in Visual Studio, publish that application to Azure in such a way that multiple sites (that I've specified) are created on Azure. Then I would like to be able to make changes to that application, and publish it again in a such a way that all the sites for it get updated all together, without requiring something be done manually per site/client.
The closest explanation I've found is this one:
http://www.wadewegner.com/2011/02/running-multiple-websites-in-a-windows-azure-web-role/
That gets me close, but what I don't understand is that when I publish this application to Azure, I still only see one application / URL available in the Azure management console. Shouldn't the extra "Site" node result in a different site being available when I publish it? Why doesn't it? Is there a completely separate way to accomplish this that I'm not using?
When you look at the management console you're seeing the web roles that you have deployed, not the sites that are part of that web role which is why you're only seeing one. As long as you've followed the instructions correctly, then yes, you do have two sites running. The catch is that you can only access the main site through that default URL. Presuming you have urls that look like customer1.mysite.com and customer2.mysite.com, you need to make sure you've set these as the host headers in the sub sites and then change your DNS so both of these domains point to URL you can see in the portal (e.g. mysite.cloudapp.net).
When considering a multi-tenant solution, ideally you should design your web-application as a single website that is capable of responding to multiple tenants (each of your customers), as opposed to creating a website/web-application for each one of them. This makes updates across the system manageable.
Your web-application can partition and identity different tenants based on several options such as part of the url (e.g myapp/tenant1 vs myapp/tenant2) or via a host header (e.g. tenant1.myapp.cloudapp.net vs tenant2.myapp.cloudapp.net)
HTH
I am building out a redesign of our corporate intranet on sharepoint 2010. We have three web applications: My sites, Team or Organization sites, and the Intranet “portal”.
On the intranet I want to read lists from Team sites of type announcements and calendar and aggregate them together. Then, on the Intranet, I’d like to have some editorial control as to what actually shows up. By default, I’d like list items to show up on the intranet, but would also like to be able to hide or delete them if deemed not important enough.
Would I benefit from using a publishing portal for the Intranet?
Would it make sense to write a web part to read the lists, sync the lists into a new list on the intranet, and then the content manager could uncheck the ‘display’ check box?
What is the best way to implement this type of infrastructure?
Where’s the documentation?
As I understand it you're wanting to syndicate lists from you Team/Organisation sites.
For this you could use a Data View Web Part connected to the lists.asmx webservice of the teams/orgs web app for a middle tier approach. You could include a field on your content types in the teams/orgs web app to indicate if a record should show on the intrnet and include that in your query when retrieving items.
As to using Publishing..... Will you have traditional web pages in your intranet? if so, then yes, use it, if not then I can't see a huge benefit.
We have both internal and external users on Windows SharePoint Services 3.0. We are using Windows Integrated authentication and have all users, both internal and external, in the same domain. We are allowing all users access to the application by adding the Domain Users group. The issue is that there are certain sites that need to be secure from the external users, but because they are in the same domain they have access. We have removed the Domain Users group from some sites and then explicitly assigned permissions to a dedicated group in Active Directory, but we have around 100 sites that we need to do this for and it would become an administrative nightmare to do this for all 100 sites.
I've done some searching and it looks like we might be able to accomplish this using zones, but when we tried last week we broke the entire application. Does anyone have any ideas?
The other option is to move the WSS server into a different domain and give the external users accounts in that domain so that we could keep them separate, but I wanted to see if there was a better way to do this.
Work on creating automation that creates and maintains Active Directory security groups that contain lists of internal or external users. Surely there is an attribute or two that distinguishes between these different types of users.
While you are at it, update your user provisioning process to make sure that when you create accounts, they get stuck in one group or another.
It would seem to be relatively simple to automate the process of changing your security using a powershell script?
An example of a script like that is here
I am planning to deploy a single-server Exchange 2007 configuration and I'd like to also start using Sharepoint for collaboration - what would the recommended deployment scenario be to accomplish this [Sharepoint will also run on its own server] to allow use of OWA + Sharepoint sites both as public resources as well as common space for document sharing etc., from inside and outside the LAN?
I am just trying to visualize but what I would like to do is:
1) Run an internal Exchange 2007 server
2) Run an internal Sharepoint 2007 server
3) Have a server which is NAT'd to the outside (for OWA and Sharepoint access) running the Exchange 2007 CAS role <- but I'm not too sure if this is needed, however I basically want to expose my OWA and Sharepoint services using a single [external] IP.
I hope I am making myself clear - I'd just like some guidance regarding the recommended configuration for what I explained above.
I'm not clear on a couple things. Specifically what you mean when you say you want to allow the use of SharePoint sites both as public resources as well as a common space for document sharing.
I take this to mean 1 of 2 scenarios (a) you want your internal users to be able to access SharePoint document libraries once they have logged in successfully to OWA. or
(b) You want to make the sites available to the public in some type of extranet scenario.
Option B opens up a whole lot of unanswered questions re: authentication as well as licensing. Hoping this is not what you want to do.
Option A - a little simpler - I can only talk generally as my experience is SP only - and this really is (as I understand it) more of an Exchange configuration issue. I believe you have to involve an ISA server for the OWA deployment. Connection to SP is pretty straightforward and well documented in TechNet.
What you get is access to the document libraries on SP sites that they user has access to. It's not the full SP site. But 90% of the time, that is sufficient.
My other piece of information is that, in order to do this - your end users must be accessing OWA via IE. Any other browser will pull up OWA "lite" which doesn't support the connection from OWA to SP.
If I'm way off, please post more details, and we can try again.