I thought I’d quickly share my experiences with installing SharePoint 2010 on the RTM version of Windows 8 with SQL Server 2012. Surprisingly this was a relatively painless experience. Here’s the high-level steps I followed:

• Installed Windows 8 RTM - awesome product!
• Installed SQL Server 2012 RTM Developer Edition.
• Followed John Livingston's blog on installing SharePoint 2010 on Windows 8 Preview. A couple of additional notes on this: 
  
  
• Windows Identity Foundation is now a feature of the Windows 8 OS which you enable through the "Turn windows features on and off". You don’t need to separately download this prerequisite, you just need to enable the Windows feature:
  
  
  
  
• As per John’s blog, the only other prerequisites I needed to install manually were as follows:
   
• Chart Controls
• SQL Server Analysis Services - ADOMD.Net
   
• Make sure you change the default .Net Framework Version in IIS Manager
  
  
• Load IIS Manager and right on the very top node in the left navigation pane (i.e. left click on the machine name).
• In the right Actions pane click on “Change .NET Framework Version”
  
  
  
  
• Set the .NET Framework Version to v2.0.50727
  
  
  
  
• The SharePoint 2010 installer uses ServerManagerCMD.exe to validate which server features and roles are installed on the machine.  Unfortunately this command has been deprecated and is no longer available on Windows 8. Currently it seems the only way to get around this is to trick the SharePoint Installer by creating a dummy ServerManagerCMD.exe file that simply returns the exit code that SharePoint is expecting (i.e. 1003). More details on this workaround can be found here as well as on the original (French) blog that provide a sample Visual Studio solution on how to build this "hack".
  
  NB: THIS IS DEFINITELY UNSUPPORTED AND I'M ASSUMING YOU ONLY DOING THIS FOR UNOFFICIAL LAB TESTING AND WON'T BE USING THIS IN ANY OFFICIAL CAPACITY OR ON A PRODUCTION ENVIRONMENT. I AM IN NO WAY ENDORCING THIS CODE - USE AT YOUR OWN RISK!
  
  I will update this blog if I find any other preferred method to get past this installation issue.

• I installed SharePoint using a slipstreamed version of SharePoint 2010 with SP1 and the June 2012 Cumulative Update package included in the slipstream (i.e. extracted to the installation Updates folder)
  
  
• If, after installing SharePoint, you get any errors accessing any web applications make sure all the applications pools used by SharePoint are all set to run under the v2.0 .NET framework version:
  
  
  
  
• Windows 8 includes PowerShell v3.0. When you load up the SharePoint Management Shell you’ll receive an error:
  
  “The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered.”
  
  
  This is because of the version of PowerShell that the SharePoint startup script is running under by default (v3.0) and SharePoint 2010 is currently not compatible with PowerShell v3.0. Fortunately this is quite easy to fix as you can run PowerShell in a previous version compatibility mode.
  Simply right click on the SharePoint Management Console icon in the taskbar and edit the properties of the shortcut:
  
  
   
  Add the “-version 2.0” flag after PowerShell.exe in the shortcut, i.e.:
  
  C:\windows\System32\WindowsPowerShell\v1.0\PowerShell.exe -Version 2.0 -NoExit  " & ' C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG\POWERSHELL\Registration\\sharepoint.ps1 ' "

That’s it! Everything else was pretty much as per John’s blog. Obviously there’s still the same limitations that applied to Windows 7 (e.g. User Profile Synchronization won’t work). I’m sure there may be other things that fail since this isn’t currently an officially supported installation configuration.


Happy SharePointing!

Brian

1. Create an anonymous web application for anonymous surveys
2. Create “anonymous” surveys on authenticated web sites

Let’s explore the pros and cons of each of these approaches and find out just how anonymous they actually are.

Create an anonymous web application for anonymous surveys

 
Firstly let’s look at some possible reasons why you might want to consider this approach:

·        You have an external facing site where users don’t log in.

·        You have an internal web site and you want to be absolutely certain that user responses to a survey are 100% confidential and anonymous.

·        You want to use only the out-of-box capabilities of the SharePoint survey module.

There are a number of blogs already out there on how to create an anonymous web application and site such as this one, as well as how to create a survey on an anonymous site such as this one, so I’m not going to repeat that right now (although later in this blog I’ll discuss this a bit more…). What I will do first though is highlight some drawbacks to this approach that I’d like discuss further:
 

·        Multiple page surveys don’t work on an anonymous site

·        Anonymous users can’t save progress

·        Intranet sites are typically not anonymous
 

Multiple page surveys don’t work on an anonymous site

 
So what exactly does this mean? Well typically longer surveys will contain multiple pages and / or branching logic. In SharePoint when you respond to a survey that has multiple pages, SharePoint automatically saves the state of the survey when you move from one page to the next. It does this so that in case you lose connectivity while completing a long survey, you’ll be able to continue where you left off. It doesn’t really matter whether there might be better ways to implement this; the fact is that SharePoint writes the work-in-progress survey to the survey list when you move to another page in the survey. The problem is that SharePoint cannot write the incomplete survey to the list unless it can associate that survey with a particular user. If the user cannot log in at the point when they move to the next page, they won’t be able to continue with the survey.
 

Anonymous users can’t save progress

 
So if the user is not logged in (i.e. anonymous) SharePoint will automatically request the user credentials. If the user is using IE (Internet Explorer) and the web site is in the Intranet zone, IE will by default automatically send through the user’s domain credentials and the user will be logged in. Alternatively the user will be prompted for credentials and if they don’t enter these credentials, they will be presented with an unauthorized dialog box:

If the user does log in, they will then move from the NewForm.aspx page to the EditForm.aspx page with the survey id as one of the query string parameters (e.g. …/EditForm.aspx?ID6&…). Since the survey is now in edit mode as opposed to new item mode, it stands to reason SharePoint needs to have the user context in order to retrieve that specific survey and to ensure the user can’t retrieve anyone else’s.  The Create responses and edit responses that were created by the user setting on the Advanced Settings page of the survey has no mean unless the user is logged in:

Thus is you want to edit the partially complete survey at this point, you simply have to be logged in.
 

Intranet sites are typically not anonymous

 
Another caveat is that Intranet sites are almost always not anonymous. To get around this you could set up a separate web site specifically for surveys where users could connect anonymously. This would entail something along these lines:

Create a new web application that supports Windows Authenticated users for survey administrators (e.g. https://survey.admin). This would normally be created in the Default zone. Create a top level site collection and grant specific permissions to the Survey Administrators so they are able to create new surveys on this site. You could further grant other permissions as necessary to any other users that may need to view survey responses or perform other actions on the site.

Extend the web application to another zone / IIS web site (e.g. to the Intranet zone on the https://survey site). Grant access to anonymous users for this zone, and remove access for Windows Authenticated users.

This will prevent users from being able to log into the https://survey web site using their Windows credentials, but survey administrators will still be able to log into the https://survey.admin web site to manage content as this is in a different zone.

Of course you still won’t be able to have multiple page surveys, but users will never be able to log into this site (https://survey) either accidently or automatically.

This method is the same approach you would typically take on an Internet facing site.

You could further enhance the user experience to create the perception of having multiple pages by incorporating some clever JavaScript / jQuery and css to show and hide sections on the survey as a user progresses through it. This would likely mean editing the NewForm.aspx page in SharePoint Designer for the specific survey you wanted to do this on. You’d then have to repeat the process for future surveys you wanted this functionality on.
 

Create “anonymous” surveys on authenticated web sites

 
So we’ve explored the first option to create an anonymous web application for surveys. This approach might work for you in many scenarios, but it may not be a viable option in other cases. Let look at an example:

 
Your organization, LitwareInc, decide to set up your company’s Annual Satisfaction Survey on the https://intranet site.

·        The survey is quite long, say 50 questions.

·        You need it to have some branching logic to probe people further when they respond in a certain way to some questions.

·        It needs to have paging so as not to put people off by presenting too many questions at once.

·        You want your employees to be able to save progress and to be able come back later to complete the survey because you realise your employees are busy and they may not be able to work through everything in one session.

·        You really want your employees to feel like their responses will be treated with confidentiality and will be completely anonymous, i.e. have no fear of repercussions from their responses because their manager found out what they were saying about them.

So your HR representative creates the survey as follows:

·        They create a new survey called “2011 Annual Satisfaction Survey”

·        Create 10 pages of questions with some branching as needed

·        Specify “No” in the survey General Settings to Show user names and “No” to Allow multiple responses.

·        In the survey advanced settings (Item-level permissions) the survey administrator ensures users can only read and edit their own responses as follows:

So let’s see what happens after a couple of users have completed this survey.
 

Surveys completed by logged in users are not truly anonymous

 
When the survey administrator sets up a survey, they have the option on the survey general settings page (Title, Description and Navigation) to specify whether user names appear in the survey results.

If they select No here, users could understandably be under the impression that their response was anonymous. As they work through a multiple-page survey, which they have to be logged on in order to do this, their user name is replaced by three asterisks ***

And in fact even when multiple users complete the survey and the survey administrator views all the responses, the survey results still appear to be anonymous:

However if the survey administrator simply goes in and changes the survey General Settings to show the user names again…

… guess what happens the survey administrator (or anyone else who has permissions to view all responses) now see when they look at the survey responses page:

So while your users might have thought nobody would ever have been able to find out what their specific response to the survey was this isn’t actually the case.
 

How to make a not-so-anonymous survey anonymous

 
The fact is that even though you specified that user names should not be shown in the survey results doesn’t mean they aren’t actually stored in the system. Furthermore the user names can easily be made visible again by simply changing an option on the settings page of the survey by the survey administrator. So what options do you have?
 

·        Accept this and trust your survey administrators to respect the privacy of the survey users.

·        Hack the SQL database tables, find the survey and remove the created by and modified by user id – this is a DEFINITE NO-NO.

·        Use the SharePoint API (object model) to set the Created By and Modified By columns to another user account.
 

If you’re happy with the first option above, then you don’t need to read further. Fantastic! If you’re even considering the second option than you shouldn’t be using SharePoint and I’m glad you’re not working at any of my customers. And if you’re still reading than hopefully I can give you some good advice!
 

You can do almost anything in SharePoint using the SharePoint API. And since using the API is supported, writing your own code to modify content is perfectly acceptable (as long as you write proper code of course and understand what you’re doing). So if we wanted to write some code to address this problem, what options could you consider? The ones I came up with are as follows:
 

·        Use a custom Workflow

·        Write a custom workflow action in Visual Studio that sets the Created By field to a specific user.

·        Create a custom workflow in SharePoint Designer that fires whenever a survey is submitted (when the Completed field is set to “Yes”).

·        Have an elevated task that calls your new custom workflow action for that survey list item. When the Created By column is updated for that survey item, the Modified By field will also automatically be updated (to the elevated system account user).
 

·        Write a custom Event Receiver feature

·        This might be scoped at the “Web” level and apply to all Survey type lists. Alternatively you’d need to implement another way to link it to specific lists on the site to trigger on.

·        The event receiver would fire whenever a "Completed" survey is submitted on any Survey list on the site.

·        The feature will set the Created By and Modified By columns for the submitted survey to the "System" account.
 

·        Use PowerShell

·        Firstly let me reference another blog where I found some guidance on doing this for lists in general: Updating the “Created By” and “Modified By” Columns in SharePoint lists using POWERSHELL

·        Now I’ll share my implementation of this, specifically for this survey requirement:
 
# ===================================================================
#
# Brian's awesome script to make surveys anonymous
#
# ===================================================================

Add-PsSnapin Microsoft.SharePoint.PowerShell

# Specify the site collection URL
set-variable -option constant -name url  -value "https://survey"
# Specify the name of the survey list
set-variable -option constant -name surveylist  -value "AnnualSurvey"

$web = Get-SPWeb $url
$list = $web.Lists[$surveylist]
$listItemCollection = $list.Items
$genericAuthor = New-Object Microsoft.SharePoint.SPFieldUserValue `
            ($web,$web.CurrentUser.ID,$web.CurrentUser.LoginName)
foreach ($listItem in $listItemCollection)
{
    $listItem["Author"]=$genericAuthor; $listItem.Update();
}
$web.Update()
$web.Dispose()

·        And this is how the list of responses I showed early looks now:

 
 
 
Note how all the Created By column values are set to the context of the account the PowerShell script was running under (in this case svc_spinstall).

·        You could either run this PowerShell script on demand or schedule this to run as frequently as needed. You should fully test this in a development environment first and possibly add error checking and do some performance optimization as needed. This is of course my standard necessary disclaimer!
 

No solution is perfect

 
It is important to note that it is unlikely that you will ever find a solution that is perfect for all scenarios. In in the final solution I proposed above, there may still be shortcomings for you. For example once the user name is unlinked from the completed survey, the user will be able to complete the survey again since there is no longer anything in the system linking them to this survey. Additionally, partially complete surveys will still have the user name associated to the survey – the onus is on the user working through the survey to complete it. Furthermore, I’m sure many of you could point out other examples of why these options may not work for you. In those scenarios perhaps InfoPath would be a better solution since this can give you much better control, although this would likely also have an associated increase in complexity. However hopefully this blog does at least give you some direction on what things you might need to consider and some possible workarounds.  Happy surveying!

Can an organization deploy a single SharePoint farm with a mixed blend of Enterprise and Standard CALs (client access licenses) for their users? What if only a small subset of users actually needs Enterprise features?  How do I control and report on which sites are using Enterprise features?

This problem is compounded because organizations are looking to consolidate their infrastructure into a single managed platform. Microsoft have embraced this by combining what used to be several products including SharePoint Server, Performance Point, InfoPath Forms Server and EPM (amongst others) into a single product with many capabilities, namely SharePoint Server 2010. So previously a company such as LitwareInc may have been using EPM for a small project management office, Performance Point for a group of users in the Finance department, and SharePoint 2007 standard for the rest of the organisation (80% of the other users). If LitwareInc upgraded to SharePoint 2010 they'd love the fact that they could consolidate their infrastructure, reduce the management overhead and save money. But if you tell organizations such as LitwareInc that if they want to consolidate their environments they have to purchase SharePoint Enterprise CALs for all their users many of these companies will think twice because they may not be able to justify the licensing cost of doing so. So the question remains can you mix Enterprise and Standard CALs on the same farm?

The general implied answer to that from a Microsoft perspective is "No". In fact if you do a search on the internet you will quickly come across a number of references to the Microsoft SharePoint FAQs that specifically state something along those lines:

https://office.microsoft.com/en-us/sharepointserver/HA101655351033.aspx

"What if some users need enterprise features and others do not?"

"Once the enterprise features of Office SharePoint Server 2007 are enabled, every client accessing enterprise functionality on that server, or servers in a farm, is required to have an Enterprise CAL in addition to their standard client access."

Of course that is still subject to interpretation, what if the users were not accessing enterprise functionality and were simply using standard functionality? It also won't take you long to realise that you will no longer be able to find this FAQ on the Microsoft website. So does that mean you can do it or not? I like Mike Walsh's answer to this:

Microsoft sometimes allow a (presumably large) company to have a certain number of Standard+Enterprise CALs and a certain number of Standard only CALs provided the customer can prove that it is impossible (i.e. they have made technical measures to block this) for the set of Standard CAL customers to access *any* Enterprise functionality.

There also appears to be some variations with regards to the interpretation of the licensing requirements depending on the country / region your company resides in. However my intent for writing this blog was not to clarify what is or isn't allowed from a licensing perspective.

I'd like to shift the focus of this blog to making an assumption that your organization has already had a discussion with your Microsoft licensing representative, and that they have told you that it is possible to have a mix of some users with Standard CALs and some users with Standard + Enterprise CALs. Now the onus is on your organization to prove that your "standard" users are not accessing "enterprise" features.

So let's take a look at what happens when you enter a SharePoint Enterprise key for your SharePoint farm. After you've entered the Enterprise license key you can enable the Enterprise Feature Set in Central Administration > Upgrade and Migration > Enable Enterprise Features

Once you've done this you get access to all the SharePoint Enterprise features. I am not going to list all those features here - you can go check out the official Microsoft SharePoint Editions comparison website for that info.

If you want to enable Enterprise features for all existing sites you can go to Central Administration > Upgrade and Migration > Enable Features on Existing Sites

The biggest two challenges for organizations that have a mixed blend of Standard CAL and Standard + Enterprise CAL users is to control and identify where Enterprise features are used in SharePoint 2010. Let's look at each of these requirements.

Controlling where Enterprise features are used

One of the first things you might notice after you've enabled Enterprise features is that there's no going back. You cannot convert the farm license type back to a standard license farm and you cannot change the Feature Set in the Central Admin site to back to Standard features. You'll also notice that after enabling the Enterprise Feature Set any new site collection or sub site you create will automatically have the Enterprise features enabled by default. So let's looks at some options to govern the use of Enterprise features:

1. Many Enterprise feature capabilities are delivered through Service Applications in SharePoint 2010, such as Excel Services, Performance Point, Project etc. The ability to use these Service Applications can be restricted to specific web applications. This means you could enable it for the https://intranet web application and disable it for https://team web application. Even better you could ensure the Enterprise Service Applications are not associated with either of those web applications in the Web Application Management page in Central Admin. You can then create another web application specifically where the Enterprise features will be used e.g. https://bi or https://project. You can further restrict / block users from accessing the new web application using a Deny All policy for users in a particular AD group (called say MyDomain/SharePointStandardUsers).
   
   
2. So restricting Enterprise Service Applications to specific web applications would immediately give you a high level of governance, however it doesn't change the fact that new site collections and sub sites will have Enterprise features enabled by default wherever they are created in the farm. So even though users may not be able to do as much if the Enterprise Service Applications aren't available to the web application, the Enterprise features would still enabled by default and policing that can be a pain. There is also not much guidance currently out there on how to prevent the Enterprise features being enabled by default, so I investigated what process causes them to get enabled in the first place. This led me to identifying a farm stapling feature that enables the Enterprise features whenever a new site or site collection is created. So the seemingly simple solution is to disable this farm stapling feature, which you can do using PowerShell:
   
   

   001	Disable-SPFeature -Identity PremiumSiteStapling -Confirm:$False

   
   After doing this, I created a new site and voilà both the Site Collection and Site Enterprise features for the new site were no longer enabled. My next thought though was what would happen if I created a site based on a template that requires Enterprise features to be enabled such as a Business Intelligence Site? Would it break? So I tested created one of those too and hey presto the Enterprise features were enabled for that site automatically. So far so good. (Now I'm waiting for all the comments that tell me what does break...)
   
   
3. Unfortunately I did find one caveat for disabling Enterprise features and there are probably others. Even when the Enterprise features are not enabled for a site or site collection, the InfoPath enterprise feature is (which also has an Enterprise CAL requirement) and there is no way to disable this though the UI. I have yet to find a supported way to prevent the InfoPath site features from being enabled automatically whenever a site collection gets created. General site users will likely never use the InfoPath customize form feature unless they have the InfoPath 2010 client installed on their workstation and they specifically choose to customize List forms, although they could unknowingly access an InfoPath form customized by someone else. It is however possible though to use PowerShell to disable the InfoPath site collection (IPFSSiteFeatures) and site (IPFSWebFeatures) features for a specific site collection or site:
   
   

   001	Disable-SPFeature IPFSSiteFeatures –Url https://yourserver/yoursite

   
   

   001	Disable-SPFeature IPFSWebFeatures –Url https://yourserver/yoursite

   
   I am sure there are some other IT Pros out there who have some suggestions on how to address this from a compliance perspective, but if we go back to what Mike Walsh was saying, it really is about intent. Has the company done everything reasonably possible to block Enterprise functionality? If one had to be pedantic, you could write a PowerShell script that runs through all sites in a web application and disables all other Enterprise features such as the InfoPath features. Then you'd need to schedule this to run occassionally to ensure the features were disabled for any new sites.

Identifying where Enterprise features are used

Ok, so now you've enabled the Enterprise Service Applications for the entire web application because one small finance site needed them and all your users are loving it because they get to enable and use all the cool Enterprise features. What now? How do you at least identify and report on where they are being used? With a bit of PowerShell script you can pretty much get out any information you want from the environment. I tried to find a PowerShell script on the internet to give me this information, but couldn't find anything suitable so I decided to write my own. Here is what I came up with:

1. PowerScript to show all web applications that have Enterprise features enabled:
   

   foreach ($webapp in Get-SPWebApplication) 
   { 
       foreach ($premiumfeature in Get-SPFeature "PremiumWebApplication" `
           -WebApplication $webapp.Url -ErrorAction SilentlyContinue) 
       { 
           Write-Host $webapp.Url 
       }
   } 

2. PowerScript to show all site collections that have Enterprise features enabled:
   

   foreach ($site in Get-SPSite -Limit All -ErrorAction SilentlyContinue)
   { 
       foreach ($premiumfeature in Get-SPFeature "PremiumSite" `
           -Site $site.Url -ErrorAction SilentlyContinue) 
       {
           Write-Host $site.Url
       }
       $site.Dispose()
   }

3. PowerScript to show all sub sites that have Enterprise features enabled:
   

   foreach ($site in Get-SPSite -Limit All -ErrorAction SilentlyContinue)
   { 
       foreach ($web in Get-SPWeb -site $site.url -Limit ALL `
           -ErrorAction SilentlyContinue) 
       { 
           foreach ($premiumfeature in Get-SPFeature "PremiumWeb" `
               -Web $web.Url -ErrorAction SilentlyContinue) 
           {
               Write-Host $web.Url, $web.Title
           }
           $web.Dispose()
       }
       $site.Dispose()
   }

Of course you could tweak the scripts above to identify where the InfoPath site features are enabled or make some modifications to output the results to csv or add some additional information such as the site owner, but you get the drift.

One additional note, these scripts assume the account running them can assess all sites. Any permission errors will be ignored (due to the SilentlyContinue flag).

Wrapping it all up

This is definitely not the be-all and end-all blog on dealing with SharePoint Enterprise licensing complexities, but hopefully it will get you thinking on some of the things that can be done with PowerShell to control and to do basic reporting on the usage of some of the Enterprise features in your environment!