Rookie call… BAD call!!!

I can’t believe that coach Jim Caldwell pulled Peyton Manning and the other Colts starters from the game in the THIRD quarter of today’s game against the Jets.  What the hell coach???!!! 

Has nobody learned ANYTHING from all the years the Colts would rest players and then proceed to LOSE in the Divisional Round of the playoffs?!

In the fierce rivalry that is the Colts-Patriots, the only thing BB&P (Belichick, Brady & Patriots) could not do was to run the table and go undefeated.  So why then, when it’s so close within their grasp, would the Colts NOT go for it?  Because you’re afraid Manning will get hurt?!   Oh please!  He’s Mr. Invincible who’s NEVER missed a single game in his career.  No, what I think it is, is a rookie call.  Don’t risk the players because IF they do get injured then you’d never be forgiven.

This is reminiscent of the Prevent Defense.  Like I always say, when you please not to lose the game, you’ll end up not winning the game… At least BB&P had the guts to go for glory…

I could forgive a coach for going for it and getting a player injured.  That’s the risk you run.  If the Colts end up NOT winning the Super Bowl this year, it would be hard to forgive the coach for giving up such a golden, once in a lifetime opportunity…  

Cheers
C

How do I? – Ensure IIS 6 has Integrated Security turned on for Anonymous access to my SharePoint site

1. Start IIS Manager.
2. Expand “Web Sites” until the web app of your site is visible.
3. Right click the web app and select “Properties” on the dropdown menu.
4. Select the “Directory Security” tab.
5. Under the “Authentication and access control” section, click the “Edit” button.
6. Check the “Enable anonymous access” check box is checked.
7. Check the “Integrated Windows authentication” check box.
8. Ensure all other check boxes are unchecked.
9. Click “OK” twice.

That should be it.  You may need to restart IIS if caching is delivering the same results as before the change.

Cheers
C

How ‘bout dem Cowboys?!

OK Tony Dungee, I have a world of respect for you, but when you said on Sunday “The Cowboys don’t have ANY hope of beating the Saints.”, you should have known you were making a dangerous statement.  That’s the same thing they said about the Patriots against the Rams in the 2001 Super Bowl.  Nothing fires up a team like being discarded.  So dear Mr. Dungee, with love and respect… EAT YOUR WORDS!!! 

Cheers
C

SharePoint Saturday Indianapolis

Mark your calendars!  We’ve finally managed to pull this one together for the local Indianapolis SharePoint community.

When:  Saturday Jan 30th, 2010  (08h30-18h00)

Where:  7435 North Keystone Ave, Indianapolis, IN 46240 @ Gene B. Glick Junior Achievement Center What:  SharePoint 2007 & 2010 More:  http://www.sharepointsaturday.org/indy/default.aspx

Be there or be square!  (Boy I just showed my age! LOL    )

Cheers
C

Dream car

Oh my goodness!  Have you seen the new e-Wolf e-2 electric sports car?!  Holy moly!  This thing is SUPER impressive.  It’s 4 wheel drive, kicks out 200 kW power and over 1,000 Nm torque and it’s light sub 1,980 lbs weight means that it gets from 0-60 mph in under 3 seconds! 

It sustains a similar pace as it blasts up to 125 mph in less than 7 seconds!  It tops out around 155 mph, but I think that’s because of a governed top speed more than anything.  Now if I had one, I’d surely hack that governor… just to see how fast it would actually go! 

Of course all electric cars have to be charged every so often, but this one charges up in under 1/2 hour and runs for 250 miles.  Not bad for an electric.

Cheers
C

My Monster VI laptop

With the coming of SharePoint 2010, I’ve had to consider my options on my old laptop.  I had an IBM Thinkpad T-60which had served me very well.  The only problem is that its 32 bit CPU won’t run SharePoint 2010 which is coming in all 64 bit format next year.  So in order to be able to deal with my VMs, I would have to upgrade.

I looked at all my options and wanted to get a new laptop that had enough iron to run all my VMs and more.  Since the latest Paradox Interactive release, Hearts of Iron III, was coming (I love that game!) and it had a hefty hardware, especially graphics, requirement, I decided to get a total monster laptop that would could handle everything I threw at it.  A desktop replacement or luggable to be sure.  I didn’t care.  I wanted the power.

I investigated all the options and even considered buying an Apple Macbook Pro for the job.  In the end there were three options I had to decide between.  A Dell XPS, an Apple Macbook Pro and an Alienware machine.  OK, I admit, the Alienware laptop wasn’t really realistic, but while you’re looking, you may as well dream, right? 

Of course price always plays into the equation so the Alienware laptop was eliminated right off the bat.  I wasn’t really ready to make a switch to Apple hardware because of the premium they put on their name.  The same hardware as the Dell, would end up being almost $1,000.00 more expensive!   I never quite understood that.  Still don’t.  Nevertheless, as I was getting ready to order the Dell, it occurred to me to check one more thing.  Back in 2002, I ordered a powerful off brand laptop (Sager) from a little company called Powernotebooks.com.  Even today it was a decent machine and back then it was top of the line.  It had a 2.4 GHz CPU with 1 GB of RAM and 128 MB of dedicated video.  It served me very well, only recently dying on me in the form of the power supply finally giving out.  I wasn’t sure if Donald Stratton (CEO) and his crew was still in business, but I decided to give it a try.  Imagine my delight when I found they were still booming along.  I customized a Sager with Intel i7 quad core processor and 6 GB of RAM (capable of holding 12, but again, cost of the top memory was just not justifiable) as well as 1 GB of dedicated video.  This monster would do it all!  The cost came in almost $1,000.00 cheaper than the XPS from Dell so I took the plunge and bought the monster Sager laptop. 

I’ve had it for a couple of months now and I absolutely LOVE this machine!  It was expensive for sure, but it’ll serve me well for many years to come… and the power supply even doubles up as a personal foot heater in winter!  

I’ve been so happy and so impressed with the guys at powernotebooks.com, that I happily recommend them to anyone in the market for some powerful portable hardware.

Cheers
C

Why passing SPBasePermissions.FullMask to SPContext.Current.Web.DoesUserHavePermissions() instead of SPBasePermissions.ManageWeb when you’re trying to determine if a user is a SPWeb administrator, is a bad idea…

OK, so the title of this post could also have been “Best Practices for Determining if a User is a SPWeb Administrator”, but then the search engines wouldn’t catch the post for all those unfortunate enough to be searching for FullMask or DoesUserHavePermissions() in the future.  The Problem OK, OK, in all seriousness though.  There are a lot of content out there that recommend that people simply useSPContext.Current.Web.DoesUserHavePermissions(SPBasePermissions.FullMask) when trying to determine if the current user has Administrator rights to the current web site (SPWeb).  This is all good and well, but it assumed that you have NEVER customized your web application available permissions list i.e. your effective base permissions.  So what’s the problem, you may be wondering… The problem is in the way SharePoint behaves when you do indeed customize your permissions for the web app.  If you dive into SharePoint Central Administration under Central Administration > Application Management > Permissions for Web Application you will find all the SharePoint base permissions and the ability to turn any one of these permissions off by simply unchecking it’s checkbox and then clicking the OK button… all except for one… FullMask.  If you were to uncheck say UseClientIntegration (in order to disable desktop apps such as Office or SPD from editing content directly on the server) and then save that state, SharePoint will do two things.

1. It will remove the UseClientIntegration bit flag from the permissions bit mask and
2. because total full control is no longer possible for the web app, it will also remove the FullMask bit flag from the mask.

That’s all fine and dandy until you go and add the permissions back again.  If you now recheck the UseClientIntegration checkbox and clicked OK, you’d expect SharePoint to add the bit flag back to the permissions mask again and it does do that, but for the UseClientIntegration flag only.  If you’re expecting it to also reset the FullMask flag, you’ll be disappointed.   This appears, at least in my mind, to be a bug in the SharePoint core code.  Yes, yes, I know it’s most probably “working as designed” or “behaving as intended”   , but in my mind the absence of any UI way to reset the FullMask flag, as well as the sparse documentation surrounding it, this just feels like a bug and not an intended feature.  So to be clear… SharePoint does not reset the FullMask security bit once permissions on the web app was customized! Now as far as SharePoint UI and everything else an end user sees is concerned, everything is working perfectly as per usual with no ill effects.  It’s only when you drop into the world of the SharePoint developer that things can become hairy.  In case you were wondering, here’s the base permissions bit mask as returned when the FullMask bit is set:7FFFFFFFFFFFFFFF And once customized, even with all permissions enabled again, the bit mask returns rather as a union of all aggregated permissions and looks like this: 400001F07FFF1BFF If a SharePoint developer used the DoesUserHavePermissions() method and passed the FullMask flag to it in hopes of identifying an admin user, the method will always return False because the FullMask bit is never reset again.  So using SPContext.Current.Web.DoesUserHavePermissions(SPBasePermissions.FullMask)simply isn’t reliable for admin checking in code.  Fortunately, the failure occurs on the safe side i.e. it is reporting an Admin to simply not be an Admin rather than reporting a User to be an Admin so most probably your app doesn’t break, but is simply not quite working as expected. The Solution So then, you ask, what exactly would be the best practice for determining if the current user is an admin? You may be tempted to use code like this((ISecurableObject)SPContext.Current.Web).DoesUserHavePermissions((SPBasePermissions)Microsoft.SharePoint.SPPermissionGroup.WebDesigner))and then use SPPermissionGroup.Administrator as the target, but since the value of Administrator in this case is –1 and the DoesUserHavePermissions() method is looking for aulong value, it will epically fail on you, even if you were to “duck punch” it with up/down casts like (SPBasePermissions)(Object)… Rather, the proper way to check if a user has admin rights to the current SPWeb, regardless of source (web, site collection or CA policy), is as follows:((ISecurableObject)SPContext.Current.Web).DoesUserHavePermissions(SPBasePermissions.ManageWeb)By checking if the user has the ManageWeb security bit set, you will always get the proper result back.  Using FullMask is akin to trying to remove a wart with a canon.  ManageWeb is more like a scalpel. OK, I broke it.  Now what? If you’re in the boat where you’ve already “broken” the FullMask bit, don’t despair.  There is indeed hope.  Luckily some smart people like MOSS MVP Gary LaPointe, have struggled with this problem before and have created clever workarounds for this. To reset the FullMask security bit, you can use the following code courtesy of Gary:

SPWebApplication wa = SPWebApplication.Lookup(new Uri(url)); 
wa.RightsMask = wa.RightsMask | SPBasePermissions.FullMask;
wa.Update()

If you’re adventurous, you can go ahead and write an app or even your own STSADM extension for that, but if you’re like me, you’ll be happy to know that Gary already did that!  Simply go and get his MOSS or WSS extension methods for STSADM package from his Download Page.  It comes all nicely packaged in a .wsp ready for deployment into your SharePoint environment.  The STSADM operation you need is: gl-enableuserpermissionforwebapp and the proper syntax for it is as follows: stsadm -o gl-enableuserpermissionforwebapp -fullmask -url http://YourWebAppURL So there you go.  The best practice for determining if a user is an administrator for a site and a way to fix it if your code is using FullMask and broke because someone played with permissions. Enjoy…

Cheers
C