If my SharePoint site's blog sits at: https://myDomain-public.sharepoint.com/blog but I want the public to see those posts when visiting http://www.myPublicSite.com/blog - an IIS8 (soon to be Azure)-based site.
What sorts infrastructure/code/configuration tasks do I have to perform? I've seen a handful of services but most seem to want to wrap my content. I'd like to treat the SP editor as a WYSIWYG tool and just pass thru whatever is formatted.
thx
Big picture: Create an 'A' record in your custom domain and configure SP's public site to resolve to that domain.
Step by step and details http://365.webbrewers.com/Pages/webbrewerstest2.aspx. His site isn't supporting a direct link to the post in question - you'll need to search out the one titled 'Use separate sub domains (or domains) for BOTH your 365 public sites!
Worth the trip if you want to accomplish something like this.
Related
I'm attempting (futilely) to create a custom advanced search page for my department's SharePoint site. I've been using this article as a guide,
http://tqclarkson.com/2007/10/26/creating-a-custom-advanced-search-box-in-moss-2007/
I've had some success copying the code of the advanced search web part and modifying it to my needs. However, I'm having some struggles with scopes.
Some background...
We are currently running MOSS 2007
Our company houses all its intranet sites under one GIGANTIC site collection
I am a site owner, but not the site collection administrator (that is controlled by IT corporate). Therefore I don't have access to central administration which houses most of the search settings.
IT has not set up any custom scopes (and just trust me when I say asking them to do so would be completely impractical).
I need to scope the advanced search web part's queries to just our site or its libraries. In a perfect world, I would just create custom scopes for this purpose, but as I mentioned that's not an option here.
I've tried using the URL property to restrict the results. Problem is the search has to be executed on EVERY RECORD in the database (which I'm sure is unfathomably huge). I did a test query which took over 5 minutes to result! Definitely not a practical solution.
So that's where I'm stuck. I need to scope the queries but can't figure out how else to do it. Any advice is welcome. Thanks as always!
We have a special situation at our office where we "close" off a site collection when a project is complete. Our architecture is setup such that each project in play is it's own site collection. When the project is complete we close the project in SP by setting the site collection to read-only.
Part of our business would like to still view the closed site collections, but doesn't want to go through a list of them (I mean excel spreadsheet or some other external form of tracking), but instead wants to do it from a page in SP. Our solution is to modify one of our other solutions (search query web part that finds all site collections they belong to) and only search on closed site collections.
I know how to determine if a site is ReadOnly or not in Powershell (#spSite.IsReadOnly), but that isn't going to work here and going through the properties in search I couldn't find anything that jumped out at me to do this. Does anyone know how to return ReadOnly site collections in a Search Query Web Part?
Thank you.
I know of a managed property called: SiteClosed but I haven't got the slightest idea what it does. Looking at the name this might be the one to start with.
If this doesn't work I'm afraid the only other option is to create a custom Web Part...
I am making a Sharepoint 2010 WebPart with functionality from another Main Web Application.
To develop the Webpart quickly I have imported the business logic assemblies used in the Main Web Application. The Webpart works and pulls application specific configuration information from the Sharepoint web.config file.
Is this the best place to store this information?
If not..
Where/How should the application specific configuration data be stored in Sharepoint?
The config data contains items like locations of web services etc. The data will only need to be edited by system administrators.
Thanks
Web.Config is, IMHO, a terrible place to store this sort of config information - its hard to deploy and hard to change, especially if you're using multiple web front ends.
The recommended way to do this is to use PropertyBag (key/value pairs) through the .Properties of SPFarm, SPWeb.RootWeb (for site collections), SPWeb, SPList etc (depending upon the scope that you need).
MSDN - Managing Custom Configuration Options for a SharePoint Application
There is a production ready code available as part of the
MSDN - The SharePoint Guidance Library
See Hierarchical configuration manager
This gives you programmatic access to read/write these values. If you want to do this without using the guidance library then you would use something like the following code.
SPWeb web = SPContext.Current.Web;
if (web.Properties.ContainsKey("MyProperty"))
string myProperty = web.Properties["MyProperty"];
If you want a UI to allow admins to easily set the values then use something like SharePoint Property Bag Settings
The easiest way to do it is to create sharepoint list visible only to administrator. It can have 3 columns description, title, value. It will store all config values. Also you can add a link to this list to site settings page.
The web config is always a good place. However if you want to change that data you will have to enforce some sort of site recompile which is a pain for end users.
Theres a nice little app/solution on codeplex to do with the property bag value
http://pbs.codeplex.com/
This is a brilliant little app/solution that ties in with your central administration.
It should be inbuilt i think.
Hope this helps.
I have created a test website that contains a single ASP.net index.aspx file that contains a gridview listing information from a MSSQL database.
I would like to have this made available as a webpart on our sharepoint intranet, how would I go about doing that?
You can just put your page under Template/Layouts and attach it to some SharePoint master page. It will look and feel like a regular SharePoint page.
Of course, that is good if you're into the quick&dirty approach :)
You will need to create a web part from the page you already have.
I would suggest isolating your gridview in a user control (ascx) instead of directly on the aspx page, it will be easier to use it in a web part that way.
To create a web part, you should probably start by downloading WSPBuilder or a similar tool that will do most of the work for you.
The following tutorial will give you the information you need on how to create a web part from a user control.
You should have no problem linking to your database or anything else. A web part behaves just like a user control.
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.