Jack of all that is Microsoft, Master of None

July 24, 2008

Got Long MOSS Service Account Names?

Are you planning on creating and using some long-named MOSS service accounts?  Maybe something like TestMOSSMySiteAdmin01 or TestMOSSSSPAppPool01?  Well if you do, then take note – I’ve had two separate occasions where I have an AD account with more than 20 characters as the username, and MOSS isn’t happy about it.  I ran across this a while ago at a client site and thought it was something wrong with their environment, and let it slide… but my buddy and fellow B&R colleague Mr. Bob Fox ran into this yesterday, and was quite surprised that this happens.

So here’s the deal…

You’ve got your account, ‘TestMOSSMySiteAdmin01’ – you go and create it in Active Directory, typically by just specifying the Full Name & User Logon Name, and your screen looks something like this:

 

 

 

 

 

 

 

 

 

 

 

 

 

Notice a couple of things here:

§  The user logon name is exactly what I want – the full account name.

§  But the ‘User Logon Name (per-Windows 2000) has been truncated by one character (character #21)

So now we hop over to our MOSS environment, as we want to bring up a new Web Application for our MySites, and use this account.  We run through the typical web app setup, and specify the full username:

 

 

 

 

 

But when we submit this information, we get a username/password combination error:

 

 

Event thought I’ve entered everything correctly. 

So after ripping my hair out, this is where the Active Directory account’s User logon name (pre-Windows 2000) comes into play.  From what I can tell, this is what MOSS is using when you input a username – so in this case, I have to truncate the name of my service account in the web application setup form:

 

Notice that I had to cut off the last number – to match what AD was showing.  Now, when I submit this, my web application gets created properly.  And to verify that it took the shortened name, I open up IIS, and voila – using the truncated account logon name:

 

 

 

And while I’m running Server 2008 with IIS7, I have confirmed this is the same on Server 2003 with IIS6. 

So in the end, the moral of the blog post is that whenever you can, keep your service account names to under 20 characters.  If you can’t beware of this issue.

-Chris

Technorati Tags:
, , , ,

June 8, 2008

Some Happenings, New CodePlex Project and More

I’ve been swamped with a few big projects lately, but I wanted to alert everyone to a couple of happenings:

  • I’m down at TechEd 2008 IT Pro this week in Orlando until Thursday afternoon with a few other members of the B&R Team – Jason Medero, Michael Lotter, Bob Fox & Josh Carlisle.  If you’d like to get together with any of us and talk SharePoint, feel free to ping me on the blog or via email – chrisr (at) bandrsolutions (dot) com.
  • Monday night is the famous ‘SharePoint by day, SharePint by Night’ event… more information on it can be found here on Bob’s blog and here on AC’s.  I’ll be there with the guys mentioned above.
  • Jay will be running the SharePoint 2003 -> 2007 Migrations Birds of a Feather session on Wednesday, June 11 at 6:30PM… it will run about an hour, and Jay will be more than happy to stay after and answer all of your questions (as long as you take him out for a drink).  Jay has done more migrations then I can count at this point, and all of different sizes.  He is a great resource to talk to (or bring it to your shop) if you need some assistance. I highly recommend this BOAF session if you are thinking of making the jump to 2007 from 2003, or you are in the middle of it.
  • My BOAF session – ‘Microsoft Office SharePoint Server 2007 and Windows Server 2008: What a Match’ is on Thursday, June 12 at 10:30AM.  Some more information on this session:  “With the launch of Windows Server 2008, there have been many discussions in the SharePoint community around whether or not SharePoint farms should be upgraded to the latest and greatest server operating system, or if administrators should take the “wait and see” approach. Based on experience so far, the answer is pretty clear—by upgrading, your life as an administrator is going to be made easier, and you will see performance gains with SharePoint. This Birds-of-a-Feather session focuses on both the technical and business drivers for upgrading sooner instead of later, and how you can go back to your manager and make a convincing argument… one that will not only save you time, but will end up helping your organization as well.”  I hope to see you there!

And then on another note, I’ve been working with Josh Carlisle on the AMD Developer Cental site, http://developer.amd.com, and Josh just released a really cool feature – ‘SharePoint Smart 404’ on CodePlex, which got its roots from the work we’ve done for AMD.  Essentially, instead of giving your users the same old boring 404 page when they type the wrong URL, the ‘smart 404 page’ will provide them with search results based on the url they were trying to hit.  To see an example of this in action, try hitting the site http://developer.amd.com/processors – this Processors site doesn’t exist – but note that you now have relevant search results around the word ‘processors’ (note the ‘Best Bets’ area).  I look forward to contributing to this project.

Until the next post,
Chris

Technorati Tags:
, , , , , , ,

April 16, 2008

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

Scenario:

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:
, , , , ,

March 17, 2008

Vote for Jason Medero & Myself – TechEd 2008 – Birds of a Feather Sessions

Hi Everyone,

Well it’s been a while since my last post… but I promise that will be changing in the near term here.  I have a lot of great things to write about, and really want to get them out here.  In the interim, I wanted to ask for your vote – for my fellow team member Jason Medero & myself.  We both submitted sessions for the ‘Birds of a Feather’ Sessions at TechEd 2008 (The ITPro Track), and they are in the final running for acceptance.  All we need is for you to vote for them:

https://www.msteched.com/itpro/voting.aspx

The session Jay needs your votes on is:

Upgrades and migrations to WSS 3.0 and MOSS 2007 the real truth

We all know that upgrades/migrations are never easy. The best way to learn and understand more about how to go about approaching your organizations migration/upgrade to V3 is by learning what others are currently finding success with. This BOF session will focus on real life upgrade/migration scenarios and how best to approach them. This includes what kind of prep work should be done, use of 3rd party tools (which ones work and which ones don’t work so well) for migration/upgrade assistance, and best practices around re-architecting your new environment according to the new MOSS 2007 site structure. The main goal of this session is to really find out what works best in specific scenarios and what things should be avoided.

And my session is:

SharePoint 2007 & Windows Server 2008 – What a Match

With the launch of Windows Server 2008, there have been many discussions in the SharePoint community around whether or not SharePoint farms should be upgraded to the latest & greatest server operating system, or if administrators should take the ‘wait and see’ approach. Based on experience so far, the answer is pretty clear – by upgrading, your life as an administrator is going to be made easier, and you will see performance gains with SharePoint. This Birds-of-a-Feather session is going to focus on both the technical and business drivers for upgrading sooner instead of later, and how you can go back to your manager and make a convincing argument… one that will not only save you time, but will end up helping your organization as well.

 

We appreciate the votes – and hope to see you at TechEd 2008 for the IT Pro (especially at our sessions!).

-Chris

Technorati Tags:
, , , , , ,

Blog at WordPress.com.