COSSharePoint.com

While it's not perfect, it does provide official documentation that issues will arise.

Below is the whole context of the ticket we submitted for documentation on this matter.

Subject: RE: [REG:115061612850630] PREM B Business hours|SharePoint Server 2013|Want to have documentation/approval from Microsoft not use [$] dollar sign on the service account name

Hello Ed,

After researching internal documentations and Collaborating with my colleagues, it was determined that the most specific things that we can provide on this is the following:

SharePoint leverages PowerShell heavily in its functionality and PowerShell views the '$' character as setting a variable to be used in storing information. Once it sees the '$' character, it views the text following it as the Variable name that it is to store the data in or retrieve data from, that may have been stored in it previously. Based on this, and how SharePoint does not utilize quotations when it is passing in an account name to the PowerShell command, it would have issues in some scenarios where it is passing in an account name that has '$' in it as it will have issues since it will most likely see the name provided as a Null variable and not as the String type of data that would occur if the '$' were not used in the account Name.

Since SharePoint uses PowerShell so heavily and is running PowerShell commands in the background when using the UI or manually running command, the use of the '$' character in account names or service account names does not fall within the Microsoft Best Practices for SharePoint 2010 or higher.

We will assist with troubleshooting issues that arise from the use of the '$' character in the Account names, however, there are some scenarios that may arise where there is nothing that can be done to correct the issue that it can cause. We would support each separate issue in a 1-on-1 basis where each specific error or issue is handled in a separate service request.

You can go through the following links to read up more on PowerShell variables:

https://technet.microsoft.com/en-us/library/ee692790.aspx
https://technet.microsoft.com/en-us/magazine/2007.03.powershell.aspx

Outside of this, and the fact that the use of the '$' character is against Microsoft Best Practices for SharePoint, we would not be able to provide any more in-depth details as to why not to use it in the Service Account names.

Based on all of the testing that has been performed on this issue, that would seem like some of the specific scenarios that you would run into with the use of the '$' character in the service account name. However, the most that we can provide is to have a separate service request to troubleshoot why it is causing those issues to see about resolving them, without having to change the service account being used.

Please let me know if you have any additional questions or concerns regarding the above information

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.