A Database Server has been cloned. The Operating System is "Microsoft Windows XP Professional Version 2002 Service Pack 3". The Query Environment is "Microsoft SQL Server 2008 Management Studio 10.0.4000.0".
After cloning, the following behaviour has been noticed. While attempting to connect from outside the machine, yet within the same domain, the following error message can be read: "Cannot generate SSPI context. (.Net SqlClient Data Provider)".
From within the machine, it is possible to connect to the Database Server using the "Microsoft SQL Server 2008 Management Studio" Query Environment.
However, when attempting to run the SQLCmd command line tool, the following error is displayed:
C:\<Directory>>SQLCmd -S DBA2\<Instance> -i C:\<Directory>\<FileName>.SQL
HResult 0x80090322, Level 16, State 1
SQL Server Network Interfaces: The target principal name is incorrect.
Sqlcmd: Error: Microsoft SQL Server Native Client 10.0 : Cannot generate SSPI context.
The ServicePrincipalNames are set the following way:
C:\PROGRA~1\SUPPOR~1>setspn DBA2
Registered ServicePrincipalNames for CN=DBA2,CN=Computers,DC=<Company>,DC=com:
VProRecovery Backup Exec System Recovery Agent 7.0/DBA2.<Company>.com
HOST/DBA2
HOST/DBA2.<Company>.com
While running the "C:\PROGRA~1\SUPPOR~1\ADSIEDIT.MSC" Support Tool from the Microsoft Windows XP Professional compact disk, we can see below the "ADSI Edit \ Domain [<Site>.<Company>.com] \ DC=<Company>,DC=com" path the "CN=Computers" leaf. In its "Properties" dialog box, inside the "Security" tab, below the "Group or user names:" list, there is the "SELF" entry. On pressing the "Advanced" button, the "Advanced Security Settings for Computers" dialog box is generated. On the "Permissions" tab, under the "Permission entries:" list, there also is an entry with the Name "SELF". By pressing the "Edit..." button, the "Permission Entry for Computers" dialog box is displayed. On its "Properties" tab, in the "Permissions:" list, there are no entries for the "Read ServicePrincipalName" permission and for the "Write ServicePrincipalName" permission.
This might be the reason why the following command fails:
C:\PROGRA~1\SUPPOR~1>setspn -r DBA2
Registering ServicePrincipalNames for CN=DBA2,CN=Computers,DC=<Company>,DC=com
HOST/DBA2.<Company>
HOST/DBA2
Failed to assign SPN to account 'CN=DBA2,CN=Computers,DC=<Company>,DC=com', 0x2098
Even if there were permissions in place for resetting the ServicePrincipalName on the cloned Database Server, would that solve the connection both from SQLCmd and from outside the machine, within the same domain?
Actually, yes, that solved the problem after the right permissions were set in the right place.
The ServicePrincipalNames had to be set on the SQL user, as follows:
C:\PROGRA~1\SUPPOR~1>setspn -a mssqlsvc/dba2:1433 <Company>\<UserName>
Registering ServicePrincipalNames for CN=<UserName>,OU=Reporting Security,OU=Security Groups,OU=Romania,DC=<Company>,DC=com
mssqlsvc/dba2:1433
Updated object
C:\PROGRA~1\SUPPOR~1>setspn -a mssqlsvc/dba2.<Company>.com:1433 <Company>\<UserName>
Registering ServicePrincipalNames for CN=<UserName>,OU=Reporting Security,OU=Security Groups,OU=Romania,DC=<Company>,DC=com
mssqlsvc/dba2.<Company>.com:1433
Updated object
C:\PROGRA~1\SUPPOR~1>setspn -l dba2
Registered ServicePrincipalNames for CN=DBA2,OU=Romania Machines,OU=Romania,DC=<Company>,DC=com:
VProRecovery Backup Exec System Recovery Agent 7.0/DBA2.<Company>.com
HOST/DBA2
HOST/DBA2.<Company>.com
C:\PROGRA~1\SUPPOR~1>setspn -l <UserName>
Registered ServicePrincipalNames for CN=<UserName>,OU=Reporting Security,OU=Security Groups,OU=Romania,DC=<Company>,DC=com:
MSSQLSvc/DBA2.<Company>.com:<Company>_RO
mssqlsvc/dba2.<Company>.com:1433
mssqlsvc/dba2:1433
Hopefully this might help somebody who could stumble into the same problem.
Related
So I have installed SQL Server 2008 R2 on windows 7 machine.I was able to login using my windows authentication.Now when I try to create a new database it gives me this error saying "CREATE DATABASE permission denied in database ‘master'".I have tried so many links related to this issue but still it is failing.These are the options that I tried:
1) Went to SQL Server Configuration Manager and then changed the parameters in the advanced tab by adding -m.It still did not help me.When I add this parameter and try to login again using windows authentication it gives me a message saying "Only one administrator can login as it is in single user mode".
2) While Installation I am sure that I added the current user under sysadmin role. I also made sure that the "Mixed mode authentication" is selected and then gave a password for the user "sa".Now when I try to use that password it says "Failed login for user sa".
3) When I login with windows authentication and then check the login mode by following this:
right click on main instance name-->Properties-->Security,it shows that only windows authentication mode is selected.But I am very much sure that I selected the "Mixed mode authentication".Not sure why it is showing it in this way.
4) I also tried to modify the password for sa but the current user has no permissions.I am not able to perform any operation with this user.
I know there are different links for this issue.But I tried all the options that were mentioned in those links but still it is giving me a problem.I have been trying to resolve this issue from a very long time.Could anyone suggest what I am missing here.
Solved! I had the same problem. I figured it out based on info from the article and the comments from the first commentor in this link.
I'll copy the author's steps with the necessary modifications in bold:
Open the Configuration Manager tool from the "SQL Server 2005| Configuration" menu
Stop the SQL Server Instance you need to recover (both SQL Server AND SQL Server Agent. Once in single user mode, if not stoped, the agent will tie up the connection, preventing you from using it with sqlcmd.exe).
In SQL Configuration Manager, click on SQL Server Services on the left, then right click on SQL Server on the right, navigate to the “Advanced” tab (or "Startup Parameters for more recent versions of SQL), and in the Properties text box add “–m” to the end of the list in the “Startup parameters” option.
Click the “OK” button and restart the SQL Server Instance (just SQL Server. Do not restart the SQL Server Agent just yet.) NOTE: make sure there is no space between “;” and “-m”, the registry
parameter parser is sensitive to such typos. You should see an entry
in the SQL Server ERRORLOG file that says “SQL Server started in
single-user mode.”
After the SQL Server Instance starts in single-user mode, the Windows Administrator account is able to connect to SQL Server using
the sqlcmd utility (it is probably here, or someplace very similar: C:\Program Files\Microsoft SQL Server\110\Tools\Binn\SQLCMD.EXE) using Windows authentication. You can use
Transact-SQL commands such as "sp_addsrvrolemember" to add an existing
login (or a newly created one) to the sysadmin server role. The
following example adds the account "Buck" in the "CONTOSO" domain to
the SQL Server "sysadmin" role: EXEC sp_addsrvrolemember
'CONTOSO\Buck', 'sysadmin'; GO
Restart/Start SQL Server Agent, back in the SQL Server Configuration Manager.
I am doing a double hop kerberos authentication from my iis to my sql server and for that I need the SQLEXPRESS service to run under a domain user.
Domain name: domain.test
service user: sqlSrv
sql server computer name : SQL
When I try to start the service this is the error I get:
Windows Could not start the SQL Server (SQLEXPRESS) on Local Computer.
For more information, review the System Event Log.
If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code 17058.
The error I see in the Event Log is:
initerrlog: Could not open error log file 'c:\Program Files\Microsoft SQL Server\MSSQ.1\MSSQL\LOG\ERRORLOG'.
Operating System error = 5 (Access is denied).
Source: MSSQL$SQLEXPRESS
Event ID: 17058
I've set up the following SPNs:
setspn -L domain.test\sqlSrv
setspn -A SQLEXPRESS/SQL:1433 domain.test\sqlSrv
setspn -A SQLEXPRESS/SQL.domain.test:1433 domain.test\sqlSrv
initerrlog: Could not open error log file 'c:\Program Files\Microsoft SQL Server\MSSQ.1\MSSQL\LOG\ERRORLOG'.
Operating System error = 5 (Access is denied).
Obviously you just replaced the service account on an existing installation. This is not supported. You need to install the service from scratch, using the desired service account.
While theoretically you could go through Configure Windows Service Accounts and Permissions and figure out what permissions are needed (in fact, figure out what local groups the service account needs to be member of), that would assume that you know what the heck you're doing.
Do it by the book. Install the service to use the desired service account. Read and follow Install SQL Server 2014 from the Command Prompt. The service account install command line parameters are described here:
SQL Server Database Engine:
Service account: /SQLSVCACCOUNT
Accountpassword: /SQLSVCPASSWORD
I had this problem when I wanted to start sqlserver service.The event viewer showed this message as you mentioned.I did my best to set permission unfortunately it did not work for me.The problem was related to "ERROLOG",its size was about 1G and it there was not the file name such as "ERRORLOG.1,ERROLLOG.2,..", so I deleted after making backup of it.at the problem disappeared.
I hope it is functional for you.
I am working on SQL Server 2008 R2 Express, when I am using SQL Server debugging feature from client pc, this error occurs:
The EXECUTE permission was denied on the object 'sp_enable_sql_debug', database 'mssqlsystemresource', schema 'sys'. (Microsoft SQL Server, Error: 229)
My user name is 'HALI' and permission is assigned to me is 'public' and 'db_Owner',
now after this error I have assigned all permissions available. And all server roles.
Now at this time I got new error message,
Error HRESULT E_FAIL has been returned from a call to a COM component. (mscorlib)
Now what the solution would be for this error.
I am not sure if disabling firewall is enough. if the user has sysadmin permissions and still getting this error means client is not able to connect to server in debugging mode. check this TCP and UDP ports are correctly open.
SQL remote debugging configuration
EDIT:1
I am sure you must have also googled a lot and tried to find out about the error messages.
What I have found so far is the Error in the OP you mentioned is misleading and from that error, we cannot tell what exactly is wrong or what to look next. But as you replied in the comments, after making changes to enable Remote Debugger; the mentioned error is more clear and I feel that proper permission is still an issue. Plenty of other suggestion you also might have tried so far, but if you haven’t done this, let's try one more time:
In one of the comments I mentioned you to try login using the windows user.
Now Keep the settings you already did for TCP ports, Firewall Exception, etc… explained in the above link.
you have windows 2012 server where you installed DB server. and windows 8 Prof where you have DB client and you connecting through SSMS. Now I believe both machines are in the same domain. Let’s say domain XYZ. You must have windows login on server, let’s say it is “XYZ\HALI” using which you can login to the Windows Server. log in and make sure that login also exists in SQL SERVER with sysadmin permission. Because client machine is also in same domain make sure you have logged in into the client machine using same user “XYZ\HALI”. Now start SSMS and choose windows authentication instead of SQL SERVER authentication. Try to start Debugging T-SQL code now.
if client and server machines are not in the same domain then we have to register server name on client machine as Linked Server, impersonate the login/user as local and then try the debugging.
Edit:2
I encountered this problem after generating a SQL 2012 script and running it in a SQL 2008 R2 database.
After some research, I found out that my target SQL 2008 R2 was running on a 32-bit OS which supports a file of up to 2GB in size. So I saved the script as C:\myScript.sql and successfully executed it in a command prompt with these steps:
Open a command prompt window.
In the command prompt window, type:
sqlcmd -S myServer\instanceName –U yourUserName –P yourPassword -i C:\myScript.sql
where myServer\instanceName is the instance name. Supply the user name and password for SQL server login, and finally the path of the file as indicated.
Press Enter.
References:
sqlcmd Utility | Microsoft Docs
Use the sqlcmd Utility | Microsoft Docs
The few times I've run across that error, it's always been firewall related. Are you working on a remote server, or your local machine? (Parenthetically, be careful assigning all possible roles. Some of them are ones you absolutely don't want. The one you need for SQL debugging is sysadmin - try disabling the rest of the roles you checked off and just assigning that one.)
Debugging procs is always a pain. This ASP.NET post helped me out substantially awhile ago.
I am trying to run openrowset from MS SQL Server on an Oracle server.
When i execute the following command:
select * from
OPENROWSET('OraOLEDB.Oracle','srv';'user';'pass',
'select * from table')
the following error occurs
Msg 7302, Level 16, State 1, Line 1
Cannot create an instance of OLE DB provider "OraOLEDB.Oracle" for linked server "(null)".
Can anyone tell me how I can use openrowset with OraOLEDB.Oracle?
I am using 64 bit version of MS SQL Server and Oracle OLEDB driver.
Edit
I have tried this on two machines running Windows 7 x64 & Windows Server 2008 x64 with MS SQL Server 2008 x64. Both showed the same error message.
In SQL Server Enterprise Manager, open \Server Objects\Linked Servers\Providers, right click on the OraOLEDB.Oracle provider, select properties and check the "Allow inprocess" option. Recreate your linked server and test again.
You can also execute the following query if you don't have access to SQL Server Management Studio :
EXEC master.dbo.sp_MSset_oledb_prop N'OraOLEDB.Oracle', N'AllowInProcess', 1
Ran into this issue where the linked server would work for users who were local admins on the server, but not for anyone else. After many hours of messing around, I managed to fix the problem using the following steps:
Run (CTRL + R) “dcomcnfg”. Navigate to “Component Services -> Computers -> My Computer -> DCOM Config”.
Open the properties page of “MSDAINITIALIZE”.
Copy the “Application ID” on the properties page.
Close out of “dcomcnfg”.
Run “regedit”. Navigate to “HKEY_CLASSES_ROOT\AppID{???}” with the ??? representing the application ID you copied in step #3.
Right click the “{???}” folder and select “Permissions”
Add the local administrators group to the permissions, grant them full control.
Close out of “regedit”.
Reboot the server.
Run “dcomconfig”. Navigate to “Component Services -> Computers -> My Computer -> DCOM Config”.
Open the properties page of “MSDAINITIALIZE”.
On the “Security” tab, select “Customize” under “Launch and Activation Permissions”, then click the “Edit” button.
Add “Authenticated Users” and grant them all 4 launch and activation permissions.
Close out of “dcomcnfg”.
Find the Oracle install root directory. “E:\Oracle” in my case.
Edit the security properties of the Oracle root directory. Add “Authenticated Users” and grant them “Read & Execute”, “List folder contents” and “Read” permissions. Apply the new permissions.
Click the “Advanced Permissions” button, then click “Change Permissions”. Select “Replace all child object permissions with inheritable permissions from this object”. Apply the new permissions.
Find the “OraOLEDB.Oracle” provider in SQL Server. Make sure the “Allow Inprocess” parameter is checked.
Reboot the server.
When connecting to SQL Server with Windows Authentication (as opposed to a local SQL Server account), attempting to use a linked server may result in the error message:
Cannot create an instance of OLE DB provider "(OLEDB provider name)"...
The most direct answer to this problem is provided by Microsoft KB 2647989, because "Security settings for the MSDAINITIALIZE DCOM class are incorrect."
The solution is to fix the security settings for MSDAINITIALIZE. In Windows Vista and later, the class is owned by TrustedInstaller, so the ownership of MSDAINITIALIZE must be changed before the security can be adjusted. The KB above has detailed instructions for doing so.
This MSDN blog post describes the reason:
MSDAINITIALIZE is a COM class that is provided by OLE DB. This class can parse OLE DB connection strings and load/initialize the provider based on property values in the connection string. MSDAINITILIAZE is initiated by users connected to SQL Server. If Windows Authentication is used to connect to SQL Server, then the provider is initialized under the logged in user account. If the logged in user is a SQL login, then provider is initialized under SQL Server service account. Based on the type of login used, permissions on MSDAINITIALIZE have to be provided accordingly.
The issue dates back at least to SQL Server 2000; KB 280106 from Microsoft describes the error (see "Message 3") and has the suggested fix of setting the In Process flag for the OLEDB provider.
While setting In Process can solve the immediate problem, it may not be what you want. According to Microsoft,
Instantiating the provider outside the SQL Server process protects the SQL Server process
from errors in the provider. When the provider is instantiated outside the SQL Server process,
updates or inserts referencing long columns (text, ntext, or image) are not allowed.
-- Linked Server Properties doc for SQL Server 2008 R2.
The better answer is to go with the Microsoft guidance and adjust the MSDAINITIALIZE security.
For error 7302 in particular, I discovered, in my registry, when looking for OraOLEDB.Oracle that the InprocServer32 location was wrong.
If that's the case, or you can't find that string in the registry, then you'll have to install or re-register the component.
I had to delete the key from the GUID level, and then find the ProgID (OraOLEDB.Oracle) key, and delete that too. (The ProgID links to the CLSID as a pair).
Then I re-registered OraOLEDB.Oracle by calling regsvr32.exe on ORAOLEDB*.dll.
Just re-registering alone didn't solve the problem, I had to delete the registry keys to make it point to the correct location. Alternatively, hack the InprocServer32 location.
Now I have error 7308, about single threaded apartments; rolling on!
Received this same error on SQL Server 2017 trying to link to Oracle 12c. We were able to use Oracle's SQL Developer to connect to the source database, but the linked server kept throwing the 7302 error.
In the end, we stopped all SQL Services, then re-installed the ODAC components. Started the SQL Services back up and voila!
Aside from other great responses, I just had to give NTFS permissions to the Oracle installation folder.
(I gave read access)
Similar situation for following configuration:
Windows Server 2012 R2 Standard
MS SQL server 2008 (tested also SQL 2012)
Oracle 10g client (OracleDB v8.1.7)
MSDAORA provider
Error ID: 7302
My solution:
Install 32bit MS SQL Server (64bit MSDAORA doesn't exist)
Install 32bit Oracle 10g 10.2.0.5 patch (set W7 compatibility on setup.exe)
Restart SQL services
Check Allow in process in MSDAORA provider
Test linked oracle server connection
Just enable option "Allow in process" on the properties of the OraOLEDB.oracle provider as below
[open server objects > Linked Severs > providers] 1 [right click on
OraOLEDB.oracle > properties ] 2 then choose optaion "Allow in
process" and click ok
I'm trying to set up a SQL Server 2012 LocalDB (RTM, x64) shared instance on my Windows 7 x64 machine and I can't seem to connect to the shared instance. I'm using an Administrator command prompt for all of the setup. Here's how I'm creating the instance:
sqllocaldb create MyInstance
Which yields the response:
LocalDB instance "MyInstance" created with version 11.0.
So far so good. Now I share the instance:
sqllocaldb share "MyInstance" "MySharedInstance"
Which results in:
Private LocalDB instance "MyInstance" shared with the shared name: "MySharedInstance".
Still looking good. At this point, I the info command yields:
.\MySharedInstance
MyInstance
v11.0
Connecting to the instance from the owner account (which is an admin) using both an admin or non-admin command prompt seems to work fine. Things come off the tracks, though, when I log in as a regular user (not a windows admin) and try to connect:
sqlcmd -S (localdb)\.\MySharedInstance
results in:
Sqlcmd: Error: Microsoft SQL Server Native Client 11.0 : Named Pipes Provider: Could not open a connection to SQL Server [2]. .
Sqlcmd: Error: Microsoft SQL Server Native Client 11.0 : Login timeout expired.
Sqlcmd: Error: Microsoft SQL Server Native Client 11.0 : A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online..
Increasing the login timeout using the "-l" switch does not help. I can connect to the default v11.0 instance, which is not shared. The info command for the non-admin user yields the same as above except withouth "MyInstance" since it's a named instance owned by the admin user. The following command (which works for the admin user/instance owner):
sqllocaldb info ".\MySharedInstance"
also results in an error:
Windows API call "FileTimeToSystemTime" returned error code: -2147024809.
So the question is why can't my non-admin user connect to my shared instance? This seems to defeat the whole purpose of shared instances. And what's with the "sqllocaldb info" command throwing an error when I try to query about the shared instance?
ANOTHER EDIT
Cory, if you have previous versions of SQL Server installed (e.g. 2008), that is the version of sqlcmd you are using. In order to connect to LocalDb you need to be using the SQL Server 2012 version of sqlcmd. So your instructions to your users must ensure that they use the SQL Server 2012 version by running:
C:\Program Files\Microsoft SQL Server\110\Tools\Binn\sqlcmd -S "(localdb)\.\InstanceName"
This worked for me. What I haven't verified is whether this path and version of sqlcmd is available to users who have only installed the sqllocaldb.msi. Sorry but I don't have any naked machines without SQL Server 2012 installed (or with only previous versions installed) to try this out thoroughly. But please let me know if explicitly calling the 110 version of sqlcmd does the trick.
I think you may also be able to instruct users to alter their system variables so that the 110 versions come first (which IMHO should be the case automatically).
The FileTimeToSystemTime has been confirmed as a bug by one of Krzysztof's co-workers. So there is still no fix that I know of for non-owners to connect via sqllocaldb. But I've shown that both SSMS and sqlcmd can be made to work, so I hope that gets you closer to running.
EDIT
You need to add any non-owner users to the instance, e.g. CREATE LOGIN [MyDomain\OtherUser] FROM WINDOWS; and any appropriate permissions as well. In my test login was failing and generating the wrong error message (the "FileTimeToSystemTime" error message is a bug). You also need to GRANT CONNECT. Once you do this, you will be able to connect from the second user using Management Studio with this connection (the only one I tried):
(localdb)\.\MySharedInstance
But from sqlcmd, I still I get an error no matter how I try to connect:
sqlcmd -S "(localdb)\.\MySharedInstance"
sqlcmd -S ".\MySharedInstance"
sqlcmd -S "(localdb)\MySharedInstance"
sqlcmd -S "GREENHORNET\MySharedInstance"
sqlcmd -S ".\LOCALDB#SH04FF8A"
sqlcmd -S "GREENHORNET\LOCALDB#SH04FF8A"
All yield:
HResult 0xFFFFFFFF, Level 16, State 1 SQL Server Network Interfaces:
Error Locating Server/Instance Specified [xFFFFFFFF].
Sqlcmd: Error:
Microsoft SQL Server Native Client 10.0 : A network-related or
instance-specific error has occurred while establishing a connection
to SQL Server. Server is not found or not accessible. Check if
instance name is correct and if SQL Server is configured to allow
remote connections. For more information see SQL Server Books Online..
Sqlcmd: Error: Microsoft SQL Server Native Client 10.0 : Login timeout
expired.
Though I have verified that the instance is set to accept remote connections. So there is some other hoop that sqlcmd must be going through.
And regarding the sqllocaldb exe, how does this follow any logic? I can see the instance is there via info, I get a proper error message when I try to stop it, I get a message that it is [already] started when I try to start it, but I can't connect to it?
So unless you need sqlcmd access, in the short term I would have the secondary users do their thing with SSMS (once you've granted adequate permissions) and hopefully Krzysztof will have more info on the other items.
Regarding the 4.0.2 update, from http://connect.microsoft.com/SQLServer/feedback/details/723737/smo-cant-connect-to-localdb-instances:
We made an explicit decision not to include .NET Framework 4.0.2 in
LocalDB installer. Installing the .NET Framework update would increase
the size of the LocalDB installer and cause a likely reboot. Since
LocalDB is built to be independent of the .NET, we didn’t think we
should take this cost for every LocalDB installation. Future .NET
versions (including .NET 4.5, now in CTP) will support LocalDB out of
the box. Some developers may also want to opt in for ODBC, PHP
Driver/PDO, and probably JDBC in the future. Those developers will not
be interested in updating .NET.
As the original post suggested, this wasn't as straight forward as anticipated, but I was eventually able to connect via the named pipe.
THIS ANSWER ASSUMES DELETING THE INSTANCE IS OK.
ie: all your data will be gone and that is okay.
I was having the same problem, after upgrading my SSMS.
sqllocaldb i
.\MyCustomInstance
sqllocaldb d
LocalDb instance ".\MyCustomInstance" does not exist!
sqllocaldb i .\MyCustomInstance
Windows API call "FileTimeToSystemTime" returned error code: -2147024809.
In order to get rid of the offending instance I had to create another MyCustomInstance which I guess will overwrite what's already there, and now you can delete it
sqllocaldb c MyCustomInstance
LocalDB instance "MyCustomInstance" created with version 11.0.
sqllocaldb d .\MyCustomInstance
LocalDB instance ".\Octopus" deleted.
Then, start the instance and share it.
Imperative you start the instance first.
sqllocaldb s MyCustomInstance
LocalDB instance "MyCustomInstance" started.
sqllocaldb h MyCustomInstance MyCustomInstance
Private LocalDB instance "MyCustomInstance" shared with the shared name: "MyCustomInstance".
Now, when you need to connect, you connect with (localdb)\.\MyCustomInstance
Install the full .NET framework 4.5.2 or later, then reboot, you should then be able to connect using:
sqlcmd -S (localdb)\.\MySharedInstance
I have found that named pipes generate a new hash when the machine is rebooted, the named shared instance will persist after reboots.
Important to note it won't work until after a reboot.
The problem is you need to quote the db name:
sqlcmd -S "(localdb)\.\MySharedInstance"