Glitch in SMO causes an error when you attempt to create an FTS Catalog/Table Population Schedule under very specific circumstances

If you connect from SQL Server Management Studio (SSMS) to an instance of SQL Server, whether it is named or default, and rather than using the proper machine name (or machine name followed by the instance name, separated by the backslash) you use either an alias (created using SQL Server Configuration Manager, through the corresponding SNAC node) or if you connect to a named instance using the localhost special token as in localhost\InstanceName, anytime you attempt to create a Catalog Population Schedule job or a Table Population Schedule job, error 14262 is raised while running sp_add_jobserver, which is triggered by SMO when the code behind the the UI (Microsoft.SqlServer.Management.SqlManagerUI.FullTextCatalogPopulationSchedule) we call ApplyToTargetServer.

Despite the error the job is created, and any schedule specified assigned to it or not depending on whether the user clicks on OK or Cancel after having acknowledged the error.

However, even though the job is created and the schedule could eventually be created too (if the user clicked OK on the error dialog box), the problem is that no steps are created inside the job, since the code to create them follows the line were the exception is thrown.

If instead of using localhost\InstanceName you use either the dot notation as in . \InstanceName or the other special token (local) as in (local)\InstanceName, it works well. And the reason is that the Server’s class in Microsoft.SqlServer.Management.Smo normalizes the server name, considering that either “.”, “(local)”, “localhost” or an empty string refer to a local default instance, while for named instances (those containing a backslash in the name) only the “.” and “(local)” are treated as those special exceptions which resolve to the machine name.