COSSharePoint.com

Colorado Springs SharePoint

Using $ in Service Account Names ( SharePoint 2013 ) Test/Results

Some time ago, I was asked to prove what errors would occur when you installed/Configured SharePoint 2013 with the $ in the service account name.  I know, weird suggestion, but our network Gods have decided that all service accounts must start with a $, and when we asked for an exception, we were told to prove it.  We asked Microsoft what the problem was since you only see it reference like below: 

The Microsoft representative we were presented with said "Hey, no problem, we'll support deployments with the $ in the name", and we were told to pound sand.  Today, we finally found proof, and I'm sharing it with you.

I had a fully functional test farm in a Hyper-V lab we used to test this.

How mine looked before

Note that this is a Hyper-V server test machine, with no GPO’s at all in our test environment at SERCO on a Stand-alone network. 

Here are the set of commands I used to show that it was currently fully operational before doing anything...

Get-SPServiceInstance | ? {($_.service.tostring()) -eq "SPDistributedCacheService Name=AppFabricCachingService"} | select Server, Status

Server                                                                  Status
------                                                                  ------
SPServer Name=SPED                                                      Online
SPServer Name=SPEDAPP1                                             Online

Get-SPServiceInstance | ? {($_.service.tostring()) -eq "SPDistributedCacheService Name=AppFabricCachingService"}

TypeName                        Status  Id
--------                        ------  --
Distributed Cache                Online  cda90885-4197-4bfe-b6d9-5f31fcd4e711
Distributed Cache                Online  d2f3d755-1538-4a20-972e-9eed188d5bc1 

CORP\sp_service was the account used.

Picture below

 

Again, I grab more details, before I break something...

PS C:\Users\sp_admin> Get-CacheHost
HostName : CachePort Service Name Service Status Version Info
-------------------- ------------ -------------- --------
SPEd.corp.contoso.com:22233 AppFabricCachingService UP 3 [3,3][1,3]
SPEDAPP1.corp.contoso.com:22233 AppFabricCachingService UP 3 [3,3][1,3]
Picture below: 

 

So now, I added our new account $SP_Test to the domain, made it a domain admin, and also added him to the ShellAdmin group (Add-SPShellAdmin), and we're ready to test.  Logged in with the new account and ran the following:  Note that NOWHERE Do I tell it to use the account name with the $ in it, it is configured when you add it.

$svc = Get-SPServiceInstance -server SPED | ? {($_.service.tostring()) -eq "SPDistributedCacheService Name=AppFabricCachingService"}
$svc.Unprovision()
$svc.delete()
$svc = Get-SPServiceInstance -server SPEDAPP1 | ? {($_.service.tostring()) -eq "SPDistributedCacheService Name=AppFabricCachingService"}
$svc.Unprovision()
$svc.delete()
Get-SPServiceInstance | ? {($_.service.tostring()) -eq "SPDistributedCacheService Name=AppFabricCachingService"} | select Server, Status
PS C:\Users\$SP_Test> Add-SPDistributedCacheServiceInstance
Add-SPDistributedCacheServiceInstance : Could not find a part of the path 'C:\U
sers\9376SP_Test\AppData\Local\Temp\DCacheAdministration2015-06-15-102722[9376]
.log'.
At line:1 char:1
+ Add-SPDistributedCacheServiceInstance
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidData: (Microsoft.Share...ServiceInstance:
   SPCmdletAddDist...ServiceInstance) [Add-SPDistributedCacheServiceInstance]
  , CmdletInvocationException
    + FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletAddDistr
   ibutedCacheServiceInstance

Picture below:

Note how the $ was replaced with 9376 in the error line

Could not find a part of the path 'C:\Users\9376SP_Test\AppData\Local\Temp\DCacheAdministration2015-06-15-102722[9376].log'.

It is important to note that the file it is looking for was actually created, however it is EMPTY (0 Bytes),  and of course exists only at the location 'C:\Users\$SP_Test\AppData\Local\Temp\DCacheAdministration2015-06-15-102722[9376].log'.

To further explain to the Network gods that this was indeed an error, I reran the same exact commands using the SP_Admin account, Picture below, ignore the first three lines, that was a copy of when I added the account to the shelladmin prior to the test:

So we've documented the whole thing, and are preparing to argue with the Network gods.  I'll update this when/if we succeed.

 

Loading