BIFocal LLC

Author: jhimmel

  • Heard good things, time to check it out

    I keep hearing good things about WordPress and with the need to move my SharePointLonghorn.com blog to a new host, I figure it’s time to see what all the fuss is about here. Most posts to come very shortly…

  • Debugging an Explorer View issue

    During a recent SharePoint 2010 upgrade project, we applied SP1 and DEC 2012 CU & encountered a frustrating issue. Everything in the farm was working as expected after we did the installation & ran PSCONFIG, except for an issue where some users could not use Explorer View to open some Document Libraries.

    More detailed user testing revealed that the issue only occurred for user who were using computers running Windows Vista or later. Windows XP users could open in explorer view without a problem.

    WebDAV vs Front Page RPC

    The reason for the OS disparity is due to the different protocols by which SharePoint will try to open in Windows Explorer. As it is explained in a Microsoft white paper from 2006 on SharePoint Explorer View:

    “The Explorer View prefers WebDAV over FPRPC. Because of the underlying design of the Explorer View and the default network provider order, it always tries to use SMB first, then WebDAV. Only when SMB and WebDAV have failed does it actually attempt to use FPRPC. This means that forcing the Explorer View to use WebDAV is more a case of creating an environment that makes sure WebDAV is successful instead of actually forcing the Explorer View to choose it.”

    While the WebDAV protocol relies on the Web Client Service, the FPRPC protocol does not, instead relying on WebFolders. WebFolders are disabled by default beginning in Windows Vista, but are available in Windows XP which explains why Explorer View worked in XP and not later Windows OS.

    Compounding the confusion

    This client was leveraging nested managed paths. This caused a secondary issue because the managed path contained a “”, causing the WebDAV protocol not to be able to parse the address. The fix simply involved creating a wildcard Managed Path for the first part of the compound address. So if you have a URL which is “statecounty” you would just add a managed path for “state” and explorer view via WebDAV will work. Here is what this would look like:

    clip_image001

    Take Away

    The lesson here is to avoid using compound Managed Paths in your SharePoint web applications. If you absolutely must use compound managed paths be sure to add a wildcard path for the first part of the compound path.

    Thank you’s

    A big thank you to Todd Klindt, of Rackspace, for giving us some good leads & Evan Riser from my team for chasing this all the way down the rabbit hole to a resolution.

  • Creating a Sysprepped Windows Server 2012 image

    One of the advantages to running Windows Server 2012 is the highly improved Hyper-V engine. In my time working on deployment scenarios I have found that creating a reliable baseline VM is critical to my success in getting farms deployed quickly and easily. To this end I have found that getting a new VM server with the OS installed to the correct level with patches, the SharePoint prerequisites, and all of the customizations that I like to have on a server already installed and ready to go in minutes is pretty important.

    This is where Sysprep comes the picture. We have been using Sysprep to prepare images since Windows XP as it allows us to generalize the critical system GUIDs and when the image is launched post-Sysprepping it will create new GUIDs and allow you to re-register the system. While this has always been a recommended practice for deploying the same VM over and over, it has not been a required function until Windows Server 2012.

    There are some drawbacks to generalizing a system that you are trying to deploy. For example, once a server has been registered in a SharePoint farm that server cannot be expected to interoperate properly once generalized. Translation: you can’t join a SharePoint server to a farm, then do a generalized Sysprep, and expect the new server to be a member of the farm. It is going to have an understandable identity crisis.

    For this reason, you will want to do your generalized Sysprep after installing SharePoint & it’s patches, but BEFORE doing your PSCONFIG. This will allow you to redeploy the image, set the computer name, a domain and then run PSCONFIG to join the server to the farm. On average this process will take about 15 or so minutes.

    Here is how you actually will perform a generalized Sysprep:

    1.) Get your image where you are happy with it

    Patch your OS. Install the softwares that you want to be able to have already ready to go. I recommend checking out some of my other posts for helpful PowerShell scripts that you will want to run to help you with some of the base OS configurations that you will find useful. “Setup your development machine right” & “Track what you are doing in PowerShell” are two good examples of this.

    2.) Take a snapshot of your VM

    This will allow you to return to the operational state you are currently in when you finish Sysprepping the image.

    3.) From command line run: “c:\windows\system32\sysprep\sysprep.exe”

    clip_image001

    4.) Choose the option to “Generalize the system”

    This is going to remove the GUIDs from the registry and allow you to create new ones upon boot. This will also remove the license key information and require that you re-register with Microsoft when you use the image. This will allow sharing of an image with others without the fear of the licensing police coming after you.

    5.) Choose the option to shut down the machine when complete

    6.) Click Ok

    7.) Once the VM is shutdown make a copy of the VM

    It is a good idea to store this in a location that you going to remember what the VM is. It is also a good idea to rename the VM folder & files so that you know that this is a generic image. You will want to give the files a new name each time you redeploy them.

    8.) Revert to your pre-Sysprepped snapshot

    As previously stated, this will return you to where you were before you started this exercise with an image ready to deploy on.

    I hope that this is as useful for you as it has been for me.

  • How to: Activate Desktop Experience in Windows Server 2012

    I ran into an issue where I needed to active that Desktop Experience in on Windows Server 2012 and found that it was not in the same place that I was expecting it to be from previous versions. Figured that this might help some people.

    Desktop Experience is required to be running if you are going to utilize OneNote, which when working in a demo server environment can be very useful. There are some DLLs that are not accessible unless you are running the Desktop Experience that are critical to applications like Snagit & Camtasia.

    Wizard Driven:

    To active the Desktop Experience go Server Manager | Local Server | Manage | Add Roles & Features

    1

    Once in the wizard under Features drill into the User Interfaces and Infrastructure and select Desktop Experience. This will active the Ink and Handwriting Services & Media Foundation features as well.

    2

    After installation the server requires a reboot to complete and will make the features active for accessing.

    PowerShell:

    From a PowerShell prompt running as Administrator use the following command:

    3

    During execution you will see the following:

    4

    Once complete you will be notified that you need to reboot the server:

    5

    Enjoy!

     notepad active Desktop Experince script

  • How to: Create Active Directory Users using PowerShell

    Not unlike several posts in recent weeks, tonight’s adventures in PowerShelling started with from a conversation at SharePoint Saturday New Hampshire with the Iowan treasure Todd Klindt. The conversation was around the script that he used to create Active Directory users. I had my own bit of jumbled together code for this purpose, but his has some snazzy ifelse-ness to it and the ability to set Managers and add Pictures that made it especially appealing.

    At the same time there were things in his script that I felt were a bit lacking and it lead to the whole “I can write that code in 2 hours” game not unlike a name that tune style geek-out.

    Rather than reiterating all of the goodness that Todd built into his version of the script I will refer you to his post: http://www.toddklindt.com/PoshMakeUsers to read all of his fun comments.

    Instead I will regale you with the updates that I have made:

    1. Specify an OU – I am an old school AD guy at heart and I HATE a mess Users directory where I can’t find anything. I always end up moving my SQL & SharePoint Service accounts to their own OU, as well as my dummy test accounts. This tweak to the script asks you what OU you want the accounts created in and then will create the OU if it doesn’t already exist (given you have those rights). If you hit enter it will default to attempting to place the accounts in an OU called “SharePoint Service Accounts”.
    2. Prompt for the CSV input file – I have multiple files that I use in different dev environments for different purposes: a.) SQL service accounts b.) SharePoint service accounts c.) Dummy user accounts d.) Smart user accounts e.) etc, etc, etc. The script now prompts for which CSV file you want to import the users from. Hitting enter when prompted will look for a file called Users.csv in the local running directory.

      **Updated**

    3. Change the default password – On Todd’s Netcast tonight he mentioned this little bit of code, however I hadn’t actually written it yet. Nothing like throwing down the gauntlet there, Mr. Klindt! In response I whipped up version 3.1 of the script which now allows you to change the default password as a variable when run. If you choose nothing it will default to the pass@word1 standard.

    Here is a copy of the code:

    # Script to create Active Directory accounts
# v3.1 11/26/2012
# Updated by Jason Himmelstein
# https://bifocal.llc
# Based upon the script by Todd Klindt
# http://www.toddklindt.com

# Add the Active Directory bits and not complain if they're already there
Import-Module ActiveDirectory -ErrorAction SilentlyContinue

$OU= Read-Host -Prompt "Enter OU name you want. Press Enter for SharePoint Service Accounts"
If ($OU -eq "") {$OU = 'SharePoint Service Accounts'}
$FQDN = (Get-ADDomain).DistinguishedName

If ([adsi]::Exists("LDAP://OU=$OU, $FQDN") -eq $True){
write-host "The OU already exist" -ForegroundColor DarkGreen -BackgroundColor Gray}
else{dsadd ou "ou=$OU,$FQDN"}

$OU_specified = "ou=$OU,$FQDN"

# specify the file location
$csvfile = 'users.csv'
$userfile = Read-Host -Prompt "
Enter the location of the CSV file containing the users you want to import. Press Enter for $csvfile"
If ($userfile -eq "") {$userfile = $csvfile}

# set default password
# change pass@word1 to whatever you want the account passwords to be
$userpassword = Read-Host -Prompt "Enter default password you wish to set for all of these accounts. Press Enter for pass@word1"
If ($userpassword -eq "") {$userpassword = 'pass@word1'}
$password = (ConvertTo-SecureString $userpassword -AsPlainText -Force)

# Get domain DNS suffix
$dnsroot = '@' + (Get-ADDomain).DistinguishedName

# Import the file with the users. You can change the filename to reflect your file
$users = Import-Csv $userfile

foreach ($user in $users) {
if ($user.manager -eq "") # In case it's a service account or a boss
 {
try {
New-ADUser -SamAccountName $user.SamAccountName -path $OU_specified -Name ($user.FirstName + " " + $user.LastName) `
-DisplayName ($user.FirstName + " " + $user.LastName) -GivenName $user.FirstName -Surname $user.LastName `
-EmailAddress ($user.SamAccountName + $dnsroot) -UserPrincipalName ($user.SamAccountName + $dnsroot) `
-Title $user.title -Enabled $true -ChangePasswordAtLogon $false -PasswordNeverExpires  $true `
-AccountPassword $password -PassThru `
                    }
catch [System.Object]
 {
Write-Output "Could not create user $($user.SamAccountName), $_"
 }
            }
 else
 {
try {
New-ADUser -SamAccountName $user.SamAccountName -path $OU_specified -Name ($user.FirstName + " " + $user.LastName) `
-DisplayName ($user.FirstName + " " + $user.LastName) -GivenName $user.FirstName -Surname $user.LastName `
-EmailAddress ($user.SamAccountName + $dnsroot) -UserPrincipalName ($user.SamAccountName + $dnsroot) `
-Title $user.title -manager $user.manager `
-Enabled $true -ChangePasswordAtLogon $false -PasswordNeverExpires  $true `
-AccountPassword $password -PassThru `
                    }
catch [System.Object]
 {
Write-Output "Could not create user $($user.SamAccountName), $_"
 }
             }
 # Put picture part here.
 $filename = "$($user.SamAccountName).jpg"
 Write-Output $filename

 if (test-path -path $filename)
            {
Write-Output "Found picture for $($user.SamAccountName)"

 $photo = [byte[]](Get-Content $filename -Encoding byte)
Set-ADUser $($user.SamAccountName) -Replace @{thumbnailPhoto=$photo} 
            }
   }

    If you are looking for the downloadable PowerShell or text file version, please find them linked below. Happy PowerShelling!

    powershell notepad

  • How to: Automatically log your PowerShell session every time

    Preface

    At SharePoint Saturday New Hampshire I sat in a packed room and listened as Todd Klindt showed everyone how to install SharePoint 2013 without screwing it up (too badly). The big take away for me was this command that I had not heard about before called start-transcript. The power of start-transcript is that it is able to write everything that you do in a PowerShell session to a log file that you can review later. Todd demo’ed how he throws this every time he opens PowerShell and has found it to be invaluable.

    The main reason that I had not heard of start-transcipt before is that I live in PowerShell ISE and rarely (if ever) go into plain ol’ PowerShell, and sadly start-transcript is not supported in PowerShell ISE. DAMN YOU POWERSHELL GODS FOR TEASING ME SO!!!!

    The Use Case

    The problem that this solves in my view is:

    1. I spend a ton of time tweaking away at some code on a SharePoint server, get it right and then inadvertently close the PowerShell window. It’s just GONE.
    2. Opening and closing PowerShell windows and trying to remember what I manually typed 2 hours ago to fix a problem that got reintroduced after redeploying code.
    3. Needing a way to review who made changes to the serverenvironment and see what they actually did.

    The more I thought about it the more the more I liked the ability to log everything that is done in PowerShell on a server, but the issue that I had was that it was something that the person opening PowerShell had to remember to do every time they opened a window.

    I started thinking about using PowerShell profiles to implement this for every user. In my experience I have seen profiles used infrequently, but in a couple of the scenarios they have been deployed via AD Group Policy. However if you are working in an environment that you don’t have access to create GPOs or you are working in a development environment and developing GPOs just isn’t your thing what do you do?

    The Problem

    The task at hand was two-fold:

    1. Auto deploy a PowerShell Profile for SharePoint Admins that would be lightweight, contain the start-transcript function to start automatically, assist in auditing, and be Server Administrator deployable
    2. Figure out if start-transcript like functionality was available for the native PowerShell ISE

    The Solution

    The solution that I came up with was to leverage the All Users Startup option in Windows to launch a script that would check to see if the folder that holds the PowerShell profile scripts exists. If it exists, the script terminates and all is well. This happens on every interactive login, but takes only a second. If the folder does not exist, the will kick off a creation of the scripts based upon a preset profile definition that includes the targeting & naming of the logs, starting the transcript, and loading the SharePoint module. The profile definition can be completely customized making this a viable approach for admins of other technologies, not just SharePoint.

    For PowerShell this is great because it works out perfectly as built. PowerShell ISE on the other hand is still a thorn in our sides. The Scripting Guys, aka Ed Wilson and Craig Liebendorfer, wrote a terrific function that allows you to log the output pane in PowerShell ISE v1 & 2. Sadly this is not working in PowerShell v3 since there is no output pane. Leveraging that we can get part of the functionality in ISE that we get in the command-line version.

    Behind the code

    The solution that I came up with is in the form of a single PowerShell script that builds the following:

    • 2 folders (at the Root of C:)
      • c:PowerShellLogs will house all of the transcripts
      • c:PowerShellScripts will be the home for the scripts used to build the profiles and will be the default starting location when PowerShell opens. This way you can put all of the scripts you want to call in one place for all users and they can launch them easily.
    • check-profiles.lnk (in the All Users Start Menu Startup folder)
      • This shortcut points to a batch file in the C:PowerShellScripts folder called check-profiles.bat
    • check-profiles.bat (in c:PowerShellScripts)
      • This batch file launches the check-profiles.ps1
    • check-profiles.ps1 (in c:PowerShellScripts)
      • This PowerShell script checks to see if the user has a WindowsPowerShell folder in their My Documents folder. If it finds the folder, the script terminates. If it doesn’t find the folder it launches the create-profiles.ps1 script
    • create-profiles.ps1 (in c:PowerShellScripts)
      • This PowerShell Script creates the profiles for both PowerShell & PowerShell ISE.

    Here is what I put in the PowerShell profile:

    • Set the location for PowerShell to start in to C:PowerShellScripts
    • Display a message about needing to Run as Administrator to effect changes
    • Set the path for logging the session to C:PowerShellLogs
    • Set the log name using the user context and date time stamp
    • Start the transcript
    • Display a message about waiting for the SharePoint snap-ins to load
    • Load the SharePoint snap-ins
    • Display a message that loading the SharePoint snap-in is complete and lets you know who you are running PowerShell as

    Here is what I put in the PowerShell ISE profile:

    • Set the location for PowerShell to start in to C:PowerShellScripts
    • Display a message about needing to Run as Administrator to effect changes
    • Set the path for logging the session to C:PowerShellLogs
    • Load a function to set the log name using the user context and date time stamp
    • Load the function for Output-ISETranscript (the Scripting Guys code)
    • Display a message about waiting for the SharePoint snap-ins to load
    • Load the SharePoint snap-ins
    • Display a message that loading the SharePoint snap-in is complete and lets you know who you are running PowerShell as

    Conclusion

    While its may not be the perfect solution for PowerShell ISE that I was looking for when I set out, at the end of the day with this code I now have the ability to automatically log everything done in command line PowerShell.

    Thanks to Todd Klindt, Evan Riser, Mark Rackley, and Dan Holme for talking through these use cases, reviewing some of the code, and taking differing view points on this to validate that it is a reasonable approach or not. I love being a part of a community where bouncing ideas and solutions off of peers is so easy and open.

    You can find the code here:

    powershell Jason’s code on GitHub

    Hopefully this code will be useful to you in your day to day world.

  • SQL Server 2012 SP1 is here & it’s huge for SharePoint 2013 BI

    This is a massive deal for SharePoint 2013 BI.  Here is an excerpt from What’s New in SQL Server 2012:

    “Business Intelligence highlights (with SQL Server 2012 SP1, Office and SharePoint Server 2013 )

    Business Intelligence highlights (with SQL Server SP1, Office and SharePoint Server 2013 Preview) are:

    • Enable self-service BI as a natural part of users day-to-day activities in Excel 2013:

    • Access and mash-up data from any source (PowerPivot). Documentation related to PowerPivot in Excel 2013 (http://go.microsoft.com/fwlink/p/?LinkID=255958).

    • Stunning visualizations and data discovery (Power View). Documentation related to Power View in Excel (http://go.microsoft.com/fwlink/p/?LinkID=255957).

    • Work with hundreds of millions of rows of data (powered by xVelocity in-memory technologies).

    • Discover, assess and audit user created spreadsheets via SharePoint Server 2013 Preview.

    • A new version of the Reporting Services add-in for SharePoint and an updated SharePoint mode report server that supports SharePoint 2013. For more information, see the following:

    • A new architecture for SQL Server 2012 SP1 CTP4 PowerPivot that supports a PowerPivot server outside a SharePoint 2013 farm. A Windows Installer package (spPowerpivot.msi) that enhances the PowerPivot for SharePoint experience. Additional features include PowerPivot Gallery, schedule data refresh, and management dashboard. For more information, see the following:

    • Share and collaborate on self-service BI assets via SharePoint Server 2013 Preview and SQL Server 2012 SP1.”

    The key takeaway and true game changer is that the SQL SSAS engine for PowerPivot is no longer required to be on a SharePoint box.  This means you no longer need a SQL license for your SharePoint App server to be able to run PowerPivot.  Don’t miss understand, you still need to license SQL to run PowerPivot, but you can do it on a separate box that can support multiple SharePoint farms and multiple Tabular BISM solutions.  Pretty huge shift.

    You can download SQL Server 2012 SP1 & SQL Server 2012 SP1 Feature Pack from these links.

    Enjoy… I know I will!

  • How to: Create a OneNote help file out of a PowerShell Module

    Being an ITPro in the current day and age I write a decent amount of PowerShell. Since I am not always on a server that has the SharePoint PowerShell modules installed most of my time on TechNet is spent basically reading the help files of specific modules to validate syntax, flags or review examples. This can become a bit of a pain after a while so I thought it would be nice to have a OneNote notebook on my SkyDrive that I could sync to my laptops or access in the cloud where I could search more easily and have all of my cmdlets at my fingertips.

    Here is how I accomplished this:

    Select the module. For this example I used the Microsoft.SharePoint.PowerShell module, however this will work with any PowerShell module.

    Run the following command to get an output of the cmdlets in the module:

    1

    Opening in Excel will give you the best opportunity to grab what you need. Column K in this particular output will list all of the cmdlets names.

    2 

    Grab just that column and copy it to a text file called “cmdlets.csv”.

    Next use the following PowerShell command to create an ANSI output file for each of the help files in the module.

    3

    For this module it created 771 individual text files. Using the OneNote 2010 Text Importer from John Guin I was able to create a single OneNote file that contains all of the help for the entire SharePoint 2013 PowerShell module that is now searchable in a faster and easier way. One caveat, I had to use OneNote 2010 for the importer to work properly.

    Not sure if this will be helpful for anyone else, but I use it all the time when writing PowerShell Code.

    4

    I will endeavor to keep this up to date, but since I just explained how to accomplish this, if I slip up you can perform the actions yourself.

    You can get download the notebook here: http://sdrv.ms/X7PqqI

    notepad  get cmdlets in the module script

    notepad  create ANSI output file for each of the help files in the module script

  • Planning a SharePoint Saturday: A recap of #SPSNH

    We are now almost a month removed from SPSNH and it has been just enough time for the glow to start to fade and for life to start getting back to normal.  The event was wildly successful and somehow managed to receive nothing but positive reviews.  There were a few things that I noted that are worth mentioning:

    1.) Drop off between registration and attendance was between 30-40%. 

    2.) Doing 6 keynotes instead of 1 made the day interesting, but did not draw people in for the early sessions the way that a big name keynote might have.

    3.) Planning 3 tracks (ITPro, Dev, End User) at 2 different skill levels (Beginner & Advanced) and keeping the tracks consistent in the same room so that people weren’t hunting for their next session was a BIG hit.

    4.) Todd Klindt is a freaking rock star.  This isn’t something that we learned, but it was certainly reinforced.  The dude stepped up to deliver a session he had never seen until 5 minutes before when someone called in sick for the first timeslot & then presented to a standing room only group later in the day.  Todd’s heroic efforts win the booby prize with Chris McNulty coming in a close second for taking on an extra session with only a day’s notice.  The edge went to Todd because he had less prep time. 

    5.) Bags and paper collateral are passé.  Give people a jump drive with digital collateral.

    6.) Varying things up between 2010 & 2013 was very positive.  The people who came to hear about 2013 wanted some 2010 as well & the folks who wanted to hear about 2010 were interested in some about 2013 too.

    7.) Hot coffee available all day is a MUST.

    8.) Speaker gifts instead of speaker shirts.  We gave a nice warm jacket with the SPSNH & NHSPUG logos on them and I am still getting twitter comments about how much the speakers enjoy them.  Plus, SPSRED “borrowed” our idea and their speakers loved them too smile

    All in all, I am happy to say that SPSNH was a great success and we are looking forward to doing it again next year.  There are things that we will look to do differently, but with a second SPSNH under our belt I think that we have a pretty good thing going up here in the “Live Free or Die” state.

    My presentation from SPSNH can be found here. The slides that Todd presented on 5 minutes notice can be found here. (I had done a webinar the week before, so this was my deck from that)

    My pictures from the weekend can be found here on my SkyDrive.

    spflogging_32

  • Office 2013 has reached RTM… SharePoint, Lync & Exchange as well.

    The big news of the [yester]day (after presenting at NHSPUG & then doing other work this post won’t actually go up until morning) is that Office 2013 has reached RTM.  Big excitement for those of us who are already huge fans, but especially exciting is the announcement that Office, SharePoint, Exchange and Lync will all be dropping at the same time.  The MSDN & TechNet availability is stated to be “mid-November” (can’t imagine what event that might coincide with​) and Volume License with SA customers will have availability by December 1.  General Availability is expected in Q1 of 2013.  For a feature overview please refer back to my post SharePoint 2013 Unveiled!​

    office While Office, SharePoint, Lync and Exchange are all completely separate products with different product teams within Microsoft and their own processes and development methodologies it is very impressive that everything has come together for this release and was announced by Kirk Koenigsbauer, the Corporate VP of the Microsoft Office Division.  It was a unified message that was echoed by the rest of the products.  We know the tight integration across this version of the stacks, but this seems like a pretty big shift to a unified stance within Microsoft. 

    SharePoint

    The biggest statement in the post from my perspective is: “We will begin rolling out new capabilities to Office 365 Enterprise customers in our next service update, starting in November through general availability.”  This suggests that the shift that many of us have been predicting is coming to pass and that true availability of this version of SharePoint is going to be in Office 365 first. 

    Lync

    The announcement coming from Kirk seems to signal that Microsoft is pushing these 4 very distinct products together and that, ready or not, Office 365 is THE future.  It seems like a question of when, not if we are going to see Microsoft abandon the on premises model for these products.  I hope that I am reading the tea leaves wrong, but that is certainly what it is looking like after today.  </prognostication>

    Exchange

    Read the entire post on the Office News Blog site here, The SharePoint Team Blog announcement can be found here, the Exchange Team Blog announcement can be found here, and the Lync Team Blog announcement can be found here.