SharePoint Experts, Information Architects, Expert Witness

We provide consulting in a broad array of business and technology from architecture to design to deployment of global systems with a focus on surfacing data in the enterprise. Specialists in Microsoft, we are a premier provider of SharePoint Expertise (including 2016 and Office 365). We also provide Expert Witness/Legal Expert in eDiscovery, source discovery, patent infringement, piracy and more! We also have established SICG DLDS s.a. - our counterpart in Costa Rica that specializes in water systems (http://www.crwatersolutions.com) - Contact me direct: david_sterling@sterling-consulting.com or call 704-873-8846 x704.

Search This Blog

Tuesday, December 24, 2013

Setting Distributed Cache Service Managed Account in SharePoint 2013

As many of you are aware, the Distributed Cache Service is a new feature for SharePoint 2013. In effect, this service is used primarily by the App Fabric service.

Once again, the Global Development Center gets it half right - while adding this service to SharePoint, they once again opt for a Powershell solution over enabling the setting like every other service.

For most, this will appear when a warning shows up in the Health Analyzer - by default, this service will be assigned to the Farm Account (hopefully) or if you followed the misguided method of using an Installation Account. Regardless, this account should be set to whatever you are using as a standard services account.

The following Powershell enables you to set this account (remember to start Powershell using 'Run as administrator'). Note that the -Identity set on the third line should be the service account to assign (note that the domain name must be specified AND verify that this account has 'Run as a service' rights!):

$farmRef = Get-SPFarm
$dCacheService = $farmRef.Services | where {$_.Name -eq "AppFabricCachingService"}
$acct = Get-SPManagedAccount -Identity sicgtmp\SPServiceAcct
$dCacheService.ProcessIdentity.CurrentIdentityType = "SpecificUser"
$dCacheService.ProcessIdentity.ManagedAccount = $acct
$dCacheService.ProcessIdentity.Update() 
$dCacheService.ProcessIdentity.Deploy()

Be aware that when the .Deploy() command is executed be prepared to WAIT (and wait, and wait some more). This can take anywhere from a few minutes to 1/2 hour or more. Can't tell you why the delay nor why it varies so much.

For a quick reference on this, see the Technet article here:
       http://technet.microsoft.com/en-us/library/jj219613.aspx


Visual Studio Project Upgrade keeps popping up

I've seen a bunch of posts for this but hate having to search again when this occurs. The issue is simple: You open a Visual Studio 2010 in 2012 or 13 (or older project in 2015/2017) and the project prompts you to convert. Once done you'd think it's all set but no, when you close it and attempt to open the project again, it does another convert!

Since I hate searching for the fix myself when I forget what it was, here it is in all the glory:

   1) Open the project folder and locate the .csproj file

   2) Edit this in notepad and locate the FileUpgradeFlag tag - this will probably look something like this (note that the number may be different but 40 seems to be common):
                     <FileUpgradeFlags>40</FileUpgradeFlags>

   3) Simply remove the number here so that the line looks like:
                      <FileUpgradeFlags></FileUpgradeFlags>

   4) Save the file and close notepad (or whatever editor you used)

   5) Open the project again by using Visual Studio 'Run as administrator' and opening up the project using the Solution (.sln) file

Viola, project opens normally and does not prompt you to convert!


Sunday, December 15, 2013

Windows 2012 to Windows 2012 R2 - VMWare Workstation VMNet0 error

Discovered a problem while upgrading our VMWare Server from Windows 2012 to 2012 R2. On successfully updating, when starting up a Virtual Machine, got the error message that VMNet0 was missing. Once the VM booted, attempting to click 'Connect' on the network adapter in settings generated an error saying that the VMNet0 was not started.

Checking the VMWare settings (Edit > Virtual Network Editor...) I found that VMNet0 was indeed missing. Adding it proved a problem since it would not allow me to set it as Bridged (error that there were no non-bridged adapters available); in short, it was there, just not visible.

Did a bit of research and found some others had similar problems with Windows 8 to 8.1 - some recommended messing with the network adapter protocols (of which I do not recommend) but the best suggestion that worked overall was to simply re-load the installation media (or use the .exe if that's what you have) and run the VMWare Install Repair (you do not have to uninstall/reinstall). After the repair is complete, do a reboot of the server.

When the server has started up completely, open the VMWare console and check the network (Edit > Virtual Network Editor...) and VMNet0 (set as auto-bridged) should be displayed. Power up the VM and the network should appear as normal.