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.
Related
My company switched from an onsite SharePoint 2013 to SharePoint Online.
I had some pages that consisted of multiple web parts, including the filter web parts.
I've rebuilt these pages in Sharepoint Online, but none of the filter web parts are available.
Every list is set to use classic experience - except the site itself, which I do not have control over.
According to IT support these specific filter web parts are simply not available in SharePoint Online, and therefore they can't help me.
I honestly don't trust that answer completely, which is why I'm asking here ;-)
So:
Can the filter web parts be made available for classic view in Sharepoint Online?
Suggestion on what would need to be configured in order for these to be made available?
Possible links to official Microsoft documentation?
Thanks :-)
Per my test, the filter web parts are available in SharePoint Online. As the below picture shows:
You could donot have access to the web part gallery. Ask the site admin to give your access to the web part gallery: please go to site settings-> Web parts, grant the user access to the library.
We are in the process of moving an on-premise SharePoint installation to SharePoint Online. We have a number of existing C# web parts that we need to convert. These web parts currently access some of our on-premise data... we need to get the web parts working on SharePoint Online; however, we're not certain of the best approach.
We've looked at BCS, but it seems that it is geared more towards synchronizing lists of data via basic CRUD methods. For many of our applications, we are not looking to synchronize lists, we are looking more towards action-oriented methods on a service that can be called on-demand as needed by the web part.
We don't believe the call can be client-side, as the users will often be accessing SharePoint Online from workstations that are not joined to our domain, and we don't want the user to have to separately authenticate to our service (i.e. we want our service to trust only the SharePoint Online backend).
Our ideal setup would be to have our C# code for the web part call into our web service (hosted on our domain, authenticating with a service account from the SPO secure store), passing the current username from the SharePoint context, and getting back a response that the web part can then use for its processing.
But as we understand, the web parts in SharePoint Online are sandboxed in such a way that they cannot make external HTTPS calls via HttpWebRequest.
We've searched for how-to examples or documentation related to our use case, and haven't found anything saying it's possible or that it's not possible. Does anybody know if it's possible for a web part to get data in this way? Is there some other direction we should be taking to achieve this?
In SharePoint online, if you are developing a SharePoint hosted app; You will be able to call external endpoints (EPs) after adding these endpoints in the manifest file.
If you haven't added these endpoint to the manifest file, This means you are not permitting the app to call an external EPs.
You don't need BCS in SharePoint online to call external EPs. Here is a sample on how to do this using JavaScript.
https://msdn.microsoft.com/en-us/library/office/fp179895.aspx
Let me know if you have any other questions.
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.
I have a bit of challenge. Knowing only the basic URL for the sharepoint installation, can I get a list of the site collections that have been created using only the basic web services that are installed?
Using the Webs web service or the SiteData web service I've been able to get information on the default site collection that's at the base URL (http://MySharePointServer/). I can also get a full list of sites below the site collection and a description of the site collection itself but I can't seem to get any info on the other site collections under the same web application.
Any help would be appreciated, I thought it would be a piece of cake to get the info.
Unfortunately, no. That functionality isn't available from the out-of-the-box web services. The only option that might work is using the Search Web Service (I'm not familiar enough with it to know).
This walkthrough describes how to add your own custom web services to the product. I strongly recommend this approach as it's very likely there will be other missing functionality you will need to add - if not now, in the near future.
I know that using SharePoint internally is free, but what if I create an application that will provide some of the data stored in SharePoint externally? Is it legal way to do things or do I have to pay for full SP licence to do that?
The cheapest option in your case may be to install WSS + Sql Server 2008 Express on Windows Server Web Edition (~£400) to avoid paying for CALs or External Connector.
Only Windows Sharepoint Services (WSS 3.0) is free and included in Windows 2003 and 2008 and thus being licensed along with it. If users need to authenticate on the site (i.e. using forms auth), then you either need a Windows CAL for each user or an External Connector License. If you do not have user accounts ("Anonymous access"), then you should not need any additional licensing.
On the other hand, Microsoft Office SharePoint Server 2007 (MOSS 2007) is a commercial product that requires licenses for any use, internal or external.
IANAL, so check with MS Licensing for this.
Using SharePoint internally is not free. You need server licenses for each server copy you have and client access lincenses (CALs) for every client that uses it - internally. There is a separate model for licensing SharePoint hosted and published externally.
You should talk to your microsoft licensing provider about this, it's not really a programming question, it's a licensing question.
There is a licensing fee for providing SharePoint connected to the intrenet. the situation where you have your own application reading data from SharePoint (e.g. webservices/rss) and exposing that to the internet is quite different and not likely to be considered for licensing.
Given that you are only exposing part of the data and none of the interface, you should be okay. If you are using CALs to access SharePoint, I believe the user running the application you access SharePoint with would use up one of those CALs.
You would really need to check with your SharePoint licensing guys to be 100%.