CONUNDRUMS

Failing to install a new instance of SQL server 2014/2016

Shreyas R Gowda — Thu, 22 Nov 2018 08:52:23 GMT

Yesterday, I was working with a client of mine on an issue with configuring SQL server reporting services over a Failover Cluster Instance. Due to issues, we had to uninstall the currently existing instance on the passive node and had to install it freshly. Before the new install attempt, we cleaned the registry entries and uninstalled the various SQL components using the below command :

WMIC PRODUCT Where "Caption like '%SQL%'" GET Caption, IdentifyingNumber

This command would list the GUIDs and using which we can uninstall the components using the command :

msiexec /X {guidnumber}

Post which I tried for a new installation of the SQL server instance, it went through all the stages, generated the configuration.ini file as well but failed at the final stage of installation with the below pop up error message :

TITLE: Microsoft SQL Server 2016 Setup ------------------------------

The following error has occurred:

Updating permission setting for file 'G:\System Volume Information\WPSettings.dat' failed. The file permission setting were supposed to be set to 'D:P(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)(A;OICI;FA;;;CO)(A;OICI;FA;;;S-1-5-80-3880718306-3832830129-1677859214-2598158968-1052248003)'.

Click 'Retry' to retry the failed action, or click 'Cancel' to cancel this action and continue setup.

For help, click: https://go.microsoft.com/fwlink?LinkID=20476&ProdName=Microsoft%20SQL%20Server&EvtSrc=setup.rll&EvtID=50000&ProdVer=13.0.5201.2&EvtType=0x88792597%25400xBB814387

------------------------------ BUTTONS:

&Retry Cancel ------------------------------

When we found the contents of the G:\ drive , it was used for the tempDB drive and thus cleared the previous contents of the tempDB drive and post which we retried the installation and things went smooth. A new instance was installed. Post which using the scale out deployment feature https://docs.microsoft.com/en-us/sql/reporting-services/install-windows/configure-a-native-mode-report-server-scale-out-deployment?view=sql-server-2017 we configured SSRS over the failover cluster instance and we thus resolved the issue. Hope this helps !! Happy installing !!

Failing to restore a database having 'In-memory OLTP' database

Shreyas R Gowda — Mon, 05 Nov 2018 09:54:58 GMT

A few days ago, encountered a weird scenario where a 'In-memory OLTP' database had to be restored from its backup and it was failing to restore - precisely getting stuck in the Recovery state. Checked the error logs and found the below log snippets and it was a SQL server 2016 SP1 instance.

2018-10-30 08:41:23.010 spidxx Starting up database 'xxxx'.

2018-10-30 08:41:23.170 spidxx [INFO] HkHostDbCtxt::Initialize(): Database ID: [x] 'xxxx'. XTP Engine version is 2.9. 2018-10-30 08:41:23.350 spidxx [INFO] HkHostDbCtxt::Initialize(): Database ID: [x] 'xxxx'. XTP Engine version is 2.9. 2018-10-30 08:41:32.950 spidxx [INFO] Database ID: [x]. Deleting unrecoverable checkpoint table row (id: 2).

2018-10-30 08:41:38.550 spidxx Recovery completed for database xxxx (database ID x) in 16 second(s) (analysis 9578 ms, redo 0 ms, undo 1 ms.) This is an informational message only. No user action is required. 2018-10-30 08:41:38.580 spidxx CHECKDB for database 'xxxx' finished without errors on 2018-10-24 18:04:24.007 (local time). This is an informational message only; no user action is required.

2018-10-30 08:41:38.580 spidxx [WARNING] Database ID: [x]. Container ID: [{xx}]. Container Path: [E:\SQLData\x\]. Failed to allocate free file in container, will try again later. Error: 0x88000028. 2018-10-30 08:41:38.580 spidxx [WARNING] Database ID: [x]. Container ID: [{xx}]. Container Path: [E:\SQLData\x\]. Failed to allocate free file in container, will try again later. Error: 0x88000028.

2018-10-30 08:41:38.580 spidxx [INFO] Database ID: [x]. Failed to open/create file of type '2' in container 'E:\SQLData\x\'. Error code: 0x88000028. Retrying the operation (1).

2018-10-30 08:41:38.580 spidxx Error: 41355, Severity: 21, State: 1. 2018-10-30 08:41:38.580 spidxx An XTP checkpoint operation encountered an error ('XTP internal error 0x88000028') while processing log record ID (335:34992:370) for database 'xxxx'. Checkpoint processing has terminated.

2018-10-30 08:41:38.580 spidxx Database xxxx was shutdown due to error 41354 in routine 'HkHostControllerCtxtImpl::WorkLoop'. Restart for non-snapshot databases will be attempted after all connections to the database are aborted.

Thus we found that the database attempted to start, followed by the database context initializing. Post which the database failed to allocate free file and thus verified the storage to find if there were any space constraints. Also we find that the XTP Checkpoint operation also encountered an error. Finally we had the the database shutdown. On research we found that by disabling all checkpoint activity by bypassing the controller, we could rectify the issue and thus we enabled the trace flag 9918 but only after upgrading the SQL server to 2016 SP2. Thus we have the issue resolved and the restore was successful !! Hope it helps!! Happy restoring!!

SQL Server Management Studio (SSMS) working only when launched as an Administrator

Shreyas R Gowda — Mon, 29 Oct 2018 09:21:24 GMT

Two weeks ago, I found one of my clients encountering an interesting issue where he found that the SQL server management studio (SSMS) works only when it is launched as an Administrator. But if it is launched as a normal user, SSMS does not work and throws exception. On launching SSMS as an user, even a simple action such as opening a new query window also threw an exception. Based on the error message, on research figured out it might be an issue with the User Access Control and thus tried disabling it referring to the article - https://docs.microsoft.com/en-us/windows/desktop/secauthz/user-account-control. Though it did not resolve the main issue, but directed the issue to show up a more precise exception. Thus, took a process monitor trace and found that it was an issue due to lack of permissions on multiple folders which showed up in the trace and by providing full permissions on those folders helped us rectify the SSMS issue. Now it is not required to open SSMS as an administrator for its required working. Hope this helps !! Happy resolving !!

What is QDS_ASYNC_QUEUE wait type ???

Shreyas R Gowda — Sat, 08 Sep 2018 14:11:37 GMT

A week ago, one of my clients' faced an issue with the SQL server performance going poor post migration from SQL 2012 to SQL 2016. On delving deeper found that QDS_ASYNC_QUEUE was the major wait type. The client did have the Query Store enabled on the subject databases and found the below information on research. As we know, Query Store feature does impact the performance of SQL server but ideally the impact is expected to be in the range of 3-5% which accounts for the fact of SQL undergoing expensive IOs while persisting the query store information from the memory to the physical storage. Internally, the Query Store itself doesn’t persist the data it holds in memory to the storage subsystem. Instead it places the data inside an asynchronous queue. From there, an internal process will write the data inside the queue to the storage subsystem. By using this asynchronous queue, the writes are not directly processed but are, instead, scheduled and the Query Store process can continue without waiting for the data write to complete. Also, it is considered that the Data Flush Interval setting controls the interval at which the Query Store persists its data to the storage subsystem. This is not completely true. The Data Flush Interval only represents the interval that Query Store data is added to the asynchronous queue. After it is placed in the queue, the speed at which the data is persisted to the storage subsystem depends on the internal asynchronous writer process. Also, it effects only the query runtime information where as Query texts and Execution Plans are added to the asynchronous queue immediately to avoid data loss of those objects. The textual explanation is clearly depicted in the flowchart below : Thus we can find that QDS_ASYNC_QUEUE wait time accounts for the sleep time of the QDS Async Persist Queue task while it is waiting for an item to be scheduled for persistence. And we can delve deeper to find the resource under concern using the perform capture of the below performance counters under SQL Server : Query Store

Query Store CPU usage
Query Store logical reads
Query Store logical writes
Query Store physical reads

In our client scenario, as they did not have an intended usage of the Query Data Store on the databases of SQL 2016 server, we were allowed to disable it and that drastically improved the performance and the jobs completed in good run time. This helped us resolve the issue. Hope this helps !! Happy better performing !!

SQL Server Failover cluster instance upgrade failure issue from 2008 R2 to 2012

Shreyas R Gowda — Wed, 15 Aug 2018 12:53:30 GMT

Today, one of my clients' production environment was facing an issue with the failed upgrade of a SQL Failover Cluster Instance from SQL 2008 R2 to SQL 2012. They were trying the upgrade since a couple of days and it was failing with the below error

TITLE: SQL Server 2008 R2 Setup ------------------------------

The following error has occurred:

The search for mount points failed. Error: The system cannot find the path specified.

For help, click: https://go.microsoft.com/fwlink?LinkID=20476&ProdName=Microsoft+SQL+Server&EvtSrc=setup.rll&EvtID=50000&ProdVer=10.50.6000.34&EvtType=0xF7F8ABE1%25400x1C2074D8%25401216%25401

------------------------------ BUTTONS:

OK ------------------------------

On checking the summary.txt logs of the Setup Bootstrap found the below information :

Overall summary: Final result: Failed: see details below Exit code (Decimal): -2067791871 Exit facility code: 1216 Exit error code: 1 Exit message: Failed: see details below Start time: 2018-08-13 08:42:14 End time: 2018-08-13 08:51:05 Requested action: Repair Log with failure: C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\Log\20180813_084025\Detail.txt Exception help link: http%3a%2f%2fgo.microsoft.com%2ffwlink%3fLinkId%3d20476%26ProdName%3dMicrosoft%2bSQL%2bServer%26EvtSrc%3dsetup.rll%26EvtID%3d50000%26ProdVer%3d10.50.6000.34%26EvtType%3d0xF7F8ABE1%400x1C2074D8%401216%401

Detailed results: Feature: Database Engine Services Status: Failed: see logs for details MSI status: Passed Configuration status: Failed: see details below Configuration error code: 0x1C2074D8@1216@1 Configuration error description: The search for mount points failed. Error: The system cannot find the path specified. Configuration log: C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\Log\20180813_084025\Detail.txt

Feature: SQL Server Replication Status: Failed: see logs for details MSI status: Passed Configuration status: Failed: see details below Configuration error code: 0x1C2074D8@1216@1 Configuration error description: The search for mount points failed. Error: The system cannot find the path specified. Configuration log: C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\Log\20180813_084025\Detail.txt

Feature: Full-Text Search Status: Failed: see logs for details MSI status: Passed Configuration status: Failed: see details below Configuration error code: 0x1C2074D8@1216@1 Configuration error description: The search for mount points failed. Error: The system cannot find the path specified. Configuration log: C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\Log\20180813_084025\Detail.txt

Thus based on the error message probed the client around the fact if there were any kind of directory changes since the last upgrade and they provided the information that the backup directory was changed and the disk was changed but it was not updated on the Backup registry value under the following registry hive:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQLServer\

Post changing that and provided the local administrator account for the below User Rights Assessment :

Act as Part of the Operating Sywstem = SeTcbPrivileg Bypass Traverse Checking = SeChangeNotify Lock Pages In Memory = SeLockMemory Log on as a Batch Job = SeBatchLogonRight Log on as a Service = SeServiceLogonRight Replace a Process Level Token = SeAssignPrimaryTokenPrivilege

These two action items helped us resolve the issue. Thus the upgrade went smooth and the client team was happy. Hope this helps !! Happy Upgrading!!

SQL Server detected a DTC/KTM in-doubt transaction

Shreyas R Gowda — Sat, 11 Aug 2018 08:23:19 GMT

Few days back, one of my clients' faced an issue with their Availability group getting into the resolving state. On checking the logs found that the issue was due to a split brain scenario and as it was a business critical issue, we resolved the issue by restarting the SQL server services on the Secondary replica. Post which the AG information with regards to its owners were clearly updated on the Failover cluster manager and thus the issue was resolved regarding the AG state. It was running as expected on the owner node and the secondary replica was also in a good shape. As a verification point, I checked the states of the stand alone databases on both the replicas and happened to see the state of one of the databases in the (Not Synchronising/ Suspect) state on the secondary replica. On checking the error logs found the below errors :

2018-07-31 16:54:47.250 spid37s SQL Server detected a DTC/KTM in-doubt transaction with UOW {DD0xxxxx-BCB0-4xx4-9B52-2xxxxF88xxxA}.Please resolve it following the guideline for Troubleshooting DTC Transactions. 2018-07-31 16:54:47.250 spid37s Error: 3437, Severity: 21, State: 3. 2018-07-31 16:54:47.250 spid37s An error occurred while recovering database 'xxx'. Unable to connect to Microsoft Distributed Transaction Coordinator (MS DTC) to check the completion status of transaction (0:857660049). Fix MS DTC, and run recovery again. 2018-07-31 16:54:47.250 spid37s Error: 3414, Severity: 21, State: 2. 2018-07-31 16:54:47.250 spid37s An error occurred during recovery, preventing the database 'xxx' (9:0) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.

On checking the environment further found that they did have MSDTC configured and checked with the client if we could proceed with losing the transaction. On his agreement, tried to abort the transaction from the MSDTC console, but failed to get the state of the database back to the online state. Thus, used the below script to find the UoW of the list of uncommitted MSDTC transactions : USE Master; GO SELECT DISTINCT(request_owner_guid) as UoW_Guid FROM sys.dm_tran_locks WHERE request_session_id =-2 GO Then, killed the UoW {DD0xxxxx-BCB0-4xx4-9B52-2xxxxF88xxxA} and restarted the SQL instance which helped us to resolve the issue and both the database and the AG were up and running as before. Hope this helps !! Happy Solving !!

Restarting the SQL Service may fail occasionally with the error, “TCP port is already in use”

Shreyas R Gowda — Tue, 17 Jul 2018 11:56:15 GMT

Today, I was working with one of my clients with an issue where the application fails to connect to SQL server. The issue was encountered with the restart of the SQL services. The initial connections go through but within a very short duration the connections starts to fail. Thus when we tried to change the port number, the issue was mitigated for just a small duration and again the issue resurfaced. From the error logs we see the below information : 2018-07-17 01:31:39.78 spid19s Server is listening on [ xx.xx.xx.xx xxxxx]. 2018-07-17 01:31:39.78 spid19s Started listening on virtual network name 'xxx'. No user action is required. 2018-07-17 01:31:39.79 spid19s Error: 26049, Severity: 16, State: 1. 2018-07-17 01:31:39.79 spid19s Server local connection provider failed to listen on [ \\.\pipe\SQLLocal\SQL2 ]. Error: 0x50 2018-07-17 01:31:39.80 spid20s A new instance of the full-text filter daemon host process has been successfully started. 2018-07-17 01:31:39.81 spid19s Error: 17182, Severity: 16, State: 1. 2018-07-17 01:31:39.81 spid19s TDSSNIClient initialization failed with error 0x50, status code 0x40. Reason: Unable to initialize the Shared Memory listener. The file exists. 2018-07-17 01:31:39.81 spid19s Error: 17182, Severity: 16, State: 1. 2018-07-17 01:31:39.81 spid19s TDSSNIClient initialization failed with error 0x50, status code 0x1. Reason: Initialization failed with an infrastructure error. Check for previous errors. The file exists. 2018-07-17 01:31:39.81 spid19s Error: 17826, Severity: 18, State: 3. 2018-07-17 01:31:39.81 spid19s Could not start the network library because of an internal error in the network library. To determine the cause, review the errors immediately preceding this one in the error log. 2018-07-17 01:31:39.81 spid19s Error: 17120, Severity: 16, State: 1. 2018-07-17 01:31:39.81 spid19s SQL Server could not spawn FRunCommunicationsManager thread. Check the SQL Server error log and the Windows event logs for information about possible related problems. On probing them, we found that they had updated their windows nodes with the KB 4338823 and on research we found that it is been documented as a known issue as per the article : https://support.microsoft.com/en-in/help/4338823/windows-7-update-kb4338823 This known issue has been resolved in the KB4345459 and once updating the nodes with this KB the issue is found to be resolved. This issue might well be caused in case of the listening named-pipes not closed properly during the last shutdown of SQL Server. Due to which there will be orphan named-pipe handles in the windows kernel file system. Since the listening pipes are opened ACLing to the current user, if you happen to switch SQL Server to run under different account, you will get error 0x05(ERROR_ACCESS_DENIED). One example of this kind of scenario is when SQL Server is shutdown by kill process. In these situations, the only fix is to either switch back to previous account and make a clean shutdown of SQL Server, or reboot the machine. In most cases, I feel the latter is faster. Hope this helps!! Happy connecting!!

Upgrade of SSRS from SQL 2008 R2 to SQL 2012

Shreyas R Gowda — Wed, 28 Mar 2018 06:28:47 GMT

Yesterday, I encountered a weird scenario where in the SSRS component was failing to upgrade from SQL 2008 R2 to SQL 2012 where in the SQL database engine and all the other components succeeded. SSRS component upgrade was failing with the below error : TITLE: Microsoft SQL Server 2012 Setup ------------------------------ The following error has occurred: A Secure Sockets Layer (SSL) certificate is not configured on the Web site. ------------------------------ On checking the Summary logs for the upgrade found that below logs for the SSRS component : Feature: Reporting Services - Native Status: Failed: see logs for details Reason for failure: An error occurred during the setup process of the feature. Next Step: The upgrade process for SQL Server failed. Use the following information to resolve the error, and then repair your installation by using this command line: setup /action=repair /instancename=MSSQLSERVER Component name: SQL Server Reporting Services Component error code: 0x80131500 Error description: A Secure Sockets Layer (SSL) certificate is not configured on the Web site. As suggested, I tried to repair the SQL server instance and even the repair failed with the below error : TITLE: Microsoft SQL Server 2012 Setup ------------------------------ The following error has occurred: The Report Server WMI provider cannot create the virtual directory. This error occurs when you call SetVirtualDirectory and the UrlString is already reserved. To continue, clear all URL reservations by calling RemoveURL and then try again. ------------------------------ Now this was a more explanatory error which indicated, that there were certain UrlString already reserved before the SetVirtualDirectory function call occurs. Thus opened the command prompt with admin privilege and ran the command netsh http show urlacl to list the Reserved URLs. With the reserved URLs, I was able to remove all those related to the Reports and ReportServer using the commands netsh http delete urlacl url=https://....../Reports/ and netsh http delete urlacl url=https://....../ReportServer/. Post which I listed all the remaining URLs using the same command netsh http show urlacl and it did not list any URLs related to the Reports and Report Server. Now when we tried to repair the SSRS component, we succeeded with the repair and eventually the component was upgraded to SQL server 2012 build. Hope this helps !! Happy Reporting !!

Sharing TDE Encrypted Backup outside the organisation.

Shreyas R Gowda — Tue, 27 Mar 2018 02:10:16 GMT

In order to share the TDE Encrypted Database backup with somebody outside the organisation, the below steps can be followed. ++ Create new temporary database in order to prepare a make-shift copy of the intended database. RESTORE DATABASE MyEncryptedDB_Temp FROM DISK = N'C:\Temp\EncryptedDatabase.bak' WITH MOVE EncryptedDatabase' TO N'C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\EncryptedDatabase_Temp.mdf', MOVE N'EncryptedDatabase_log' TO N'C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\EncryptedDatabase_Temp_log.ldf'; GO ++ Disable TDE on the new temporary database in order to reset the certificate and the DEK and then re-enable it with the new ones. ALTER DATABASE EncryptedDatabase_Temp SET ENCRYPTION OFF; GO ++ Remove Original Database Encryption Key USE EncryptedDatabase_Temp; GO DROP DATABASE ENCRYPTION KEY; ++ Create a new certificate to encrypt temporary database USE master; GO CREATE CERTIFICATE TemporaryTDECert WITH SUBJECT='To encrypt temporary DB'; GO ++ Create new database encryption key USE EncryptedDatabase_Temp; GO CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256 ENCRYPTION BY SERVER CERTIFICATE TemporaryTDECert; ++ Backup the new temporary certificate USE master; GO BACKUP CERTIFICATE TemporaryTDECert TO FILE = 'C:\temp\TemporaryTDECert.cer' WITH PRIVATE KEY (file='C:\temp\TemporaryTDECert.pvk', ENCRYPTION BY PASSWORD='Password to backup'); ++ Enable TDE on the temporary Database. This time the database will pick the newly created certificate for encryption. ALTER DATABASE EncryptedDatabase_Temp SET ENCRYPTION ON; GO ++ Backup the new temporary database BACKUP DATABASE EncryptedDatabase_Temp TO DISK = N'C:\temp\EncryptedDatabase_Temp.bak'; ++ Provide outside organization with database backup, certificate backup, and private key backup files. C:\temp\EncryptedDatabase_Temp.bak C:\temp\TemporaryTDECert.cer C:\temp\TemporaryTDECert.pvk ++ Now as we have achieved the required outcome of sharing the TDE encrypted database outside the organisation, we can clear the make-shift temporary database and certificate. EXEC msdb.dbo.sp_delete_database_backuphistory @database_name = N'EncryptedDatabase_Temp'; GO USE master; GO DROP DATABASE EncryptedDatabase_Temp; DROP CERTIFICATE TemporaryTDECert; Hope this helps !! Happy Sharing !!

SSMS 2016/2017 has the Tools -> Options -> Source control missing for the integration of TFS server

Shreyas R Gowda — Tue, 06 Mar 2018 14:24:42 GMT

Encountered a weird thing when I was working on a TFS server integration issue yesterday where in we were unable to integrate the TFS server with the SQL Server. The option to integrate it is as shown below under the Tools menu : But upfront we do not see this option in the SSMS 2016/ SSMS 2017 as we notice below : Here is the action plan to rectify this issue : ++ Install Visual Studio 2015 on your SSMS machine. ++ Edit the ssms.pkgundef file found at C:\Program Files (x86)\Microsoft SQL Server\130\Tools\Binn\ManagementStudio\ssms.pkgundef as follows (The path shown is in case of SSMS 16 and under the 140 folder in case of SSMS 17) At the beginning of this file there are a series of packages grouped together related to TFS Source Control features. These packages will be removed from the pkgundef file by commenting them out using ‘//’ which blocks the Team Explorer from loading. So we need to uncomment the package series by removing the ‘//’ for the following statements. // Microsoft.VisualStudio.TeamFoundation.VersionControl.HatPackage //[$RootKey$\AutoLoadPackages\{4CA58AB2-18FA-4F8D-95D4-32DDF27D184C}] // Microsoft.VisualStudio.TeamFoundation.Lab //[$RootKey$\Packages\{17c5d08a-602c-4dfb-82b5-8e0f7f50c9d7}] // GitHub Package //[$RootKey$\Packages\{c3d3dc68-c977-411f-b3e8-03b0dccf7dfc}] // Team Foundation Server Provider Package //[$RootKey$\Packages\{5BF14E63-E267-4787-B20B-B814FD043B38}] // Microsoft.VisualStudio.TeamFoundation.WorkItemTracking.WitPcwPackage //[$RootKey$\Packages\{6238f138-0c0c-49ec-b24b-215ee59d84f0}] // Microsoft.VisualStudio.TeamFoundation.Build.BuildPackage //[$RootKey$\Packages\{739f34b3-9ba6-4356-9178-ac3ea81bdf47}] // Microsoft.VisualStudio.TeamFoundation.WorkItemTracking //[$RootKey$\Packages\{ca39e596-31ed-4b34-aa36-5f0240457a7e}] // Microsoft.VisualStudio.TeamFoundation //[$RootKey$\Packages\{b80b010d-188c-4b19-b483-6c20d52071ae}] // Microsoft.TeamFoundation.Git.Provider.SccProviderPackage //[$RootKey$\Packages\{7fe30a77-37f9-4cf2-83dd-96b207028e1b}] // Microsoft.VisualStudio.TeamFoundation.VersionControl.SccPcwPluginPackage //[$RootKey$\Packages\{1b4f495a-280a-3ba4-8db0-9c9b735e98ce}] // Microsoft.VisualStudio.TeamFoundation.VersionControl.HatPackage //[$RootKey$\Packages\{4CA58AB2-18FA-4F8D-95D4-32DDF27D184C}] // Visual SourceSafe Provider Package //[$RootKey$\Packages\{AA8EB8CD-7A51-11D0-92C3-00A0C9138C45}] // Visual SourceSafe Provider Stub Package [$RootKey$\Packages\{53544C4D-B03D-4209-A7D0-D9DD13A4019B}] // Microsoft.VisualStudio.TeamFoundation.Initialization.InitializationPackage [$RootKey$\Packages\{75DF55D4-EC28-47FC-88AC-BE56203C9012}] // Team Foundation Server Provider Stub Package [$RootKey$\Packages\{D79B7E0A-F994-4D4D-8FAE-CAE147279E21}] // Microsoft.VisualStudio.Services.SccDisplayInformationPackage [$RootKey$\Packages\{D7BB9305-5804-4F92-9CFE-119F4CB0563B}] // Microsoft.VisualStudio.TeamFoundation.Lab.LabPcwPluginPackage [$RootKey$\Packages\{e0910062-da1f-411c-b152-a3fc6392ee1f}] [$RootKey$\ToolsOptionsPages\Source Control] [$RootKey$\AutoLoadPackages\{11b8e6d7-c08b-4385-b321-321078cdd1f8}] // TFS SCC Configuration entries. ++ Save the file and restart SSMS to see the Teams menu and the Plug-in selection option as shown above in the first snap. Hope this helps!! Happy resolving!!