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.