Jack of all that is Microsoft, Master of None

April 16, 2008

Web Content Management – Allow reviewers to see drafts and nothing else


You have a public-facing site with WCM/Publishing enabled.  Active Directory authentication is used for your content creators, editors & approvers.  Your anonymous users can browse most portions of the site without logging in, however, there are some areas where they login using forms-based authentication.

Your pages are constantly undegoing changes, and you need to create an account that has access to review the draft version of pages, however, you do not want them to see the Site Actions button or the Page Editing Toolbar, or have the ability to create any new content.  Essentially, they are the most basic of content reviewers – the only ‘elevated permissions’ they have over an FBA user is that when they browse the site, they see the latest draft of every page, instead of the latest published version.

The Typical Solution

So in most situations, you would turn content approval on within your page libraries, and then add this user to the <SITE> Members SharePoint group, where they would be granted contributor rights, and could review the page drafts.  They would be able to edit the drafts, but since content approval is turned on, anything they modify won’t go anywhere without approval.  But they are contributors, and can create new content (that they cannot publish), and they still have access to the Site Actions menu, even if the functionality available to them is significantly limited.  In the majority of cases though, this setup works exactly as needed for most organizations.

Our Scenario’s Solution

In our case, we need to create a new Permission Level:

1.  Browse to Site Actions -> Site Settings -> Modify all Site Settings -> Advanced Permissions.

2.  Click Settings -> Permission Levels.

3.  Click on the actual ‘Contribute’ link.

4.  You will now be presented with a page listing all of the permissions for contributors.  We want to make a copy of this permissions set, and then modify the new permission level.  Scroll down to the bottom of the page and click on Copy Permission Level.

5.  A new page will appear where we can now customize our new permission level.  Give this level the name of Draft Reviewers, or whatever you see fit.

6.  Then, make sure only the boxes checked in the images below are checked on your page.  This will ensure that any users granted this Draft Reviewers permissions level will be able to see drafts but not do anything else ‘elevated’ within the site.  Once you have checked (and double checked) your settings, click Okay.

7.   Once the permission levels has been created, go back to Permissions in your breadcrumb.

8.   Now we need to create the SharePoint group that will hold these Draft Reviewers and also assign them the permissions set we just created.  Click on New -> SharePoint Group.

9.  Give your group a name (such as Draft Reviewers) and then make sure you check the box next to the new permission level we just created:

10.  Click Okay – and congratulations, your new group is created with the proper permission based on the scenario above.  Now, add your users to the group, and when they log into the site, they will see all of the pages in draft form, but perform any other type of content management process or administrator function.

 Technorati Tags:
, , , , , , ,


April 11, 2008

More than 1 SSL-Secured SharePoint Site on 1 IP Address in IIS7

Filed under: IIS7, MOSS 2007, SharePoint, SharePoint 2007 — Tags: , , , — cregan @ 3:55 am

I was doing some work this evening on B&R’s own internal SharePoint sites, and I ran into an issue that kept me scratching my head for quite a while.  Here’s the scenario:

We have a really nice Windows Server 2008 box that runs all of our MOSS 2007 sites.  On the box, we have 5 different web applications within IIS7 – all for different purposes, such as (for example):

my.company.com -> My Sites

extranet.company.com -> Extranet Site

customers.company.com -> Customer Portal

And to save a few hundred dollars, I went and purchased a wildcard SSL certificate from RapidSSL (I really like these guys – cheap, quick, and I’ve never had a problem with them).  For those of you that are not familiar with wildcard SSL certificates, they essentially allow you to SSL-secure all of your sites, so long as they have the same root domain, which in this case would be company.com.  So the SSL cert actually secures *.company.com.  Therefore, I can have hundreds of subdomains, and only pay for the one certificate, versus explicitly-named certificates for each site.

Now, what I wanted to do was to SSL-secure each one of the three sites, but have them all function on the SAME IP Address.  I didn’t want to have to allocate 3 different IP addresses just so SSL would work without conflicts (I could have assigned each site a different port, but I wanted everything running on 443 as well).

I did quite a bit of reading online, and I found a mixed bag – some individuals saying that this couldn’t be done, and others saying it could.  Well – I’m here to tell – it can be done (and in particular, in this case, in IIS7)!  But the main caveat is that you must purchase a wildcard certificate

So here’s how you do it:

1.  Request, purchase & install your wildcard SSL certificate (make sure that in your request the common name = *.domain.extension).  A great primer on requesting & installing SSL certs in IIS7 can be found here.

2.  You create (or extend) a new SSL-enabled web application within Central Administration.  Be sure that you specify port 443, a host header (so SharePoint knows what to respond to), and you check the radio button to ‘Yes’ under ‘Use SSL’.  The image below is an example of the settings (note, in particular, that under URL you see ‘https://&#8217; and ‘:443’ automatically added):

3. Once your new SSL web application is created, you will want to open up IIS and take a look.  Note that if you already have another SSL site up and running, that site will be stopped, since this new site is conflicting with that one (don’t worry about this).  Click on the Sites folder, and take a look at the new site you created – notice something… no host header:

4. Okay – so no big deal, you can just edit the bindings, right?  Wrong.  Highlight the name of your site and then click on the Bindings action… and see what you get:

So you’ve got HTTPS, the proper port, and the proper certificate – but host name is grayed out… cripes.  This is where the command line comes into play so you can be an IT Hero again.

5.  Crack open the command prompt.  

6. Browse to C:\Windows\System32\Inetsrv

7.  You are going to run the following command:

appcmd set site /site.name:SITENAME /bindings.[protocol=’https’,bindingInformation=’*:443:’].bindingInformation:*:443:HOSTHEADER

So in my case, where my SITENAME = SharePoint_Extranet_SSL and I want the HOSTHEADER = extranet.company.com, my command would look like:

appcmd set site /site.name:SharePoint_Extranet_SSL /bindings.[protocol=’https’,bindingInformation=’*:443:’].bindingInformation:*:443:extranet.company.com

8.  If all goes well, you will receive the confirmation message:

SITE object “SharePoint_Extranet_SSL” changed 

In addition, if you Refresh your Sites list, you will see:

And if you highlight the web site itself and look over in the actions right-hand window pane, you can also see the SSL host header set there as well:

9.  So congratulations – your first SSL host header is configured.  Now repeat the process for each additional one under that root domain, and you’re set.

Some Important Notes:

1. This will not work if you want to use one IP address for 2 different SSL certificates under different domains (such as site.xyzcompany.com & site.yourcompany.com).  This is specifically for sites that will run under the same root domain.

2. If you receive the error ERROR ( message:Cannot find requested collection element. ) after running the command, make sure that you spelled the site name exactly as it appears within IIS.  If you still can’t get it to work, follow my alternate host header setting instructions listed below.

3. If you edit the bindings for the site you’ve performed this configuration on, you will see something like:

Which looks good – but then if you highlight that binding and click Edit, you will see:

Notice that the host name is gone – don’t worry about it – this is (I assume) because you cannot edit SSL Host Headers through the UI and must use the command prompt.  My word to the wise – don’t touch the bindings for these sites through the UI!

Alternate Instructions for Adding the Host Header Binding:

1.  Backup the file C:\Windows\System32\Inetsrv\config\applicationHost.config and then open it up in your favorite editor.

2.  Perform a search for the web site you want to edit (in my case, SharePoint_Extranet_SSL).  Your search should find the web site along with some related configuration data, just like what you see in the image:

 The main area you want to focus on is between <bindings>, as you will want to add your host header after the port – “:443:hostheader” />

So in my case, the binding protocol line would like:

<binding protocol=”https” bindingInformation=”:443:extranet.company.com” />

3.  Save this file, refresh IIS, and you will see your change made.  Once again, repeat this for every SSL site, and you are set to go!

Technorati Tags:
, , , , ,

Create a free website or blog at WordPress.com.