Update to remove sscurrent-md.md from file table.

MikeRayMSFT · MikeRayMSFT · commit a08585d95dae · 2021-02-04T08:51:48.000-08:00
diff --git a/docs/database-engine/log-shipping/upgrading-log-shipping-to-sql-server-2016-transact-sql.md b/docs/database-engine/log-shipping/upgrading-log-shipping-to-sql-server-2016-transact-sql.md
@@ -65,14 +65,15 @@ To preserve your log shipping disaster recovery solution, upgrade, or apply serv
  While the monitor server is being upgraded, the log shipping configuration continues to work, but its status is not recorded in the tables on the monitor. Any alerts that have been configured will not be triggered while the monitor server is being upgraded. After the upgrade, you can update the information in the monitor tables by executing the [sp_refresh_log_shipping_monitor](../../relational-databases/system-stored-procedures/sp-refresh-log-shipping-monitor-transact-sql.md) system stored procedure.   For more information about a monitor server, see [About Log Shipping &#40;SQL Server&#41;](../../database-engine/log-shipping/about-log-shipping-sql-server.md).  
   
 ##  <a name="UpgradeSecondaries"></a> Upgrading the Secondary Server Instances  
- The upgrade process involves upgrading the secondary server instances of [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] to [!INCLUDE[ssnoversion](../../includes/ssnoversion-md.md)] before upgrading the primary server instance. Always upgrade the secondary [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] instances first. Log shipping continues throughout the upgrade process because the upgraded secondary server instances continue to restore the log backups from [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] primary server instance. If the primary server instance is upgraded before the secondary server instance, log shipping will fail because a backup created on a newer version of [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] cannot be restored on an older version of [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)]. You can upgrade the secondary instances simultaneously or serially, but all secondary instance must be upgraded before the primary instance is upgraded to avoid a log shipping failure.  
+
+The upgrade process involves upgrading the secondary server instances of [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] before upgrading the primary server instance. Always upgrade the secondary [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] instances first. Log shipping continues throughout the upgrade process because the upgraded secondary server instances continue to restore the log backups from primary server instance. If the primary server instance is upgraded before the secondary server instance, log shipping will fail because a backup created on a newer version of [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] cannot be restored on an older version of [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)]. You can upgrade the secondary instances simultaneously or serially, but all secondary instance must be upgraded before the primary instance is upgraded to avoid a log shipping failure.  
   
- While a secondary server instance is being upgraded, the log shipping copy and restore jobs do not run. This means that unrestored transaction log backups will accumulate on the primary and you need to have sufficient space to hold these unrestored backups. The amount of accumulation depends on the frequency of scheduled backup on the primary server instance and the sequence in which you upgrade the secondary instances. Also, if a separate monitor server has been configured, alerts might be raised indicating restores have not been performed for longer than the configured interval.  
+While a secondary server instance is being upgraded, the log shipping copy and restore jobs do not run. This means that unrestored transaction log backups will accumulate on the primary and you need to have sufficient space to hold these unrestored backups. The amount of accumulation depends on the frequency of scheduled backup on the primary server instance and the sequence in which you upgrade the secondary instances. Also, if a separate monitor server has been configured, alerts might be raised indicating restores have not been performed for longer than the configured interval.  
   
  Once the secondary server instances have been upgraded, the log shipping agents jobs resume and continue to copy and restore log backups from the primary server instance to the secondary server instances. The amount of time required for the secondary server instances to bring the secondary database up to date varies, depending on the time taken to upgrade the secondary server instance and the frequency of the backups on the primary server.  
   
 > [!NOTE]  
->  During the server upgrade, the secondary database itself is not upgraded to a [!INCLUDE[ssnoversion](../../includes/ssnoversion-md.md)] database. It will get upgraded only if it is brought online by initiating a failover of the log shipped database. In theory, this condition could persist indefinitely. The amount of time to upgrade the database metadata when a failover is initiated is small.  
+> During the server upgrade, the secondary database itself is not upgraded the new version. It will get upgraded only if it is brought online by initiating a failover of the log shipped database. In theory, this condition could persist indefinitely. The amount of time to upgrade the database metadata when a failover is initiated is small.  
   
 > [!IMPORTANT]  
 >  The RESTORE WITH STANDBY option is not supported for a database that requires upgrading. If an upgraded secondary database has been configured by using RESTORE WITH STANDBY, transaction logs can no longer be restored after upgrade. To resume log shipping on that secondary database, you will need to set up log shipping again on that standby server. For more information about the STANDBY option, see [Restore a Transaction Log Backup &#40;SQL Server&#41;](../../relational-databases/backup-restore/restore-a-transaction-log-backup-sql-server.md).  
diff --git a/docs/relational-databases/blob/enable-the-prerequisites-for-filetable.md b/docs/relational-databases/blob/enable-the-prerequisites-for-filetable.md
@@ -142,7 +142,7 @@ GO
   
 -   When you attach or restore a database, the operation fails if the new database has a value for **DIRECTORY_NAME** that already exists in the target instance. Specify a unique value for **DIRECTORY_NAME** when you call **CREATE DATABASE FOR ATTACH** or **RESTORE DATABASE**.  
   
--   When you upgrade an existing database to [!INCLUDE[ssCurrent](../../includes/sscurrent-md.md)], the value of **DIRECTORY_NAME** is null.  
+-   When you upgrade an existing database, the value of **DIRECTORY_NAME** is null.  
   
 -   When you enable or disable non-transactional access at the database level, the operation does not check whether the directory name has been specified or whether it is unique.  
   
