locked
How do I remove a no-longer-existent node from scale-out deployment that is "Waiting to join"? RRS feed

  • Question

  • During build of a clustered SQL2012 instance, Reporting Services was missed on the passive node and in an effort to add it post-engine-install, MSSQLSERVER2 became the designated instance name for RS.

    Now that the cluster has been torn down and rebuilt correctly, the passive node shows the node-name DB2 as Joined using the correct default instance name, but I still have the non-existent instance's server "Waiting to join".

    As you can see, I can't "Remove Server", so I need a back-door clean-up script, please.

    Can anyone help, please?


    • Edited by SAinCA Wednesday, October 17, 2012 7:35 PM
    Wednesday, October 17, 2012 7:35 PM

Answers

  • This is an old thread but I wanted to provide a resolution since none was given above. I encountered the exact sitution as described by SAinCA.

    The rskeymgmt utility cannot be used to remove the stray "Waiting to Join' entry because the GUID associated with that entry is not valid. The fix is to remove the row for the stray entry in the [ReportServer].[dbo].[Keys] table inthe ReportServer database. You will see three rows in the table, two of which will have a matching machine name (38-DB2 in SAinCA's case). One of those two rows will have a NULL value in the SymmetricKey column. Deleting that row will remove the rogue "Waiting to Join" entry from your Scale-Out Deployment screen in SSRS Config Manager.

    • Marked as answer by SAinCA Friday, May 23, 2014 10:29 PM
    Thursday, May 22, 2014 2:16 PM

All replies

  • The first link's instructions do not work on SQL2012.  Using RSKeyMgmt –l (lower-case L) gives: "Unrecognized argument -l"

    Same for link 2, even when cd'd to the folder cited.

    It appears that Microsoft has WITHDRAWN the -l Argument, despite the installed program emitting it as an example, per below:

    C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn>RSKeyMgmt /?
    Microsoft (R) Reporting Services Key Manager
    Version 11.0.2100.60 x86
    
    Performs key management operations on a local report server.
    
      -e  extract           Extracts a key from a report server instance
      -a  apply             Applies a key to a report server instance
      -s  reencrypt         Generates a new key and reencrypts all encrypted
                            content
      -d  delete content    Deletes all encrypted content from a report server
                            database
      -l  list              Lists the report servers announced in the report server
                            database
      -r  installation ID   Remove the key for the specified installation ID
      -j  join              Join a remote instance of report server to the
                            scale-out deployment of the local instance
      -i  instance          Server instance to which operation is applied;
                            default is MSSQLSERVER
      -f  file              Full path and file name to read/write key.
      -p  password          Password used to encrypt or decrypt key.
      -m  machine name      Name of the remote machine to join to the
                            scale-out deployment
      -n  instance name     Name of the remote machine instance to join to the
                            scale-out deployment
      -u  user name         User name of an administrator on the machine to join to
                            the scale-out deployment.  If not supplied, the current
                            user is used.
      -v  password          Password of an administrator on the machine to join to
                            the scale-out deployment
      -t  trace             Include trace information in error message
    
    To create a back-up copy of the report server encryption key:
    RSKeyMgmt -e [-i <instance name>] -f <file> -p <password>
    
    To restore a back-up copy of the report server encryption key:
    RSKeyMgmt -a [-i <instance name>] -f <file> -p <password>
    
    To reencrypt secure information using a new key:
    RSKeyMgmt -s [-i <instance name>]
    
    To reset the report server encryption key and delete all encrypted content:
    RSKeyMgmt -d [-i <instance name>]
    
    To list the announced report servers in the report server database:
    RSKeyMgmt -l [-i <instance name>]
    
    To remove a specific installation from a scale-out deployment:
    RSKeyMgmt -r <installation ID> [-i <instance name>]
    
    To join a remote machine to the same scale-out deployment as the local machine:
    RSKeyMgmt -j [-i <local instance name>] -m <remote machine name>
              [-n <remote instance name>] [-u <user name> -v <password>]

    BOL omits -l at rskeymgmt Utility (SSRS) for SQL Server 2012.

    There appears to be no method of listing as in prior releases...

    Oversight?  Deliberate unpublished withdrawal?  No mention of this in SQL Server 2012 Reporting Services Discontinued Functionality

    Any insights?


    Wednesday, October 17, 2012 10:29 PM
  • This is an old thread but I wanted to provide a resolution since none was given above. I encountered the exact sitution as described by SAinCA.

    The rskeymgmt utility cannot be used to remove the stray "Waiting to Join' entry because the GUID associated with that entry is not valid. The fix is to remove the row for the stray entry in the [ReportServer].[dbo].[Keys] table inthe ReportServer database. You will see three rows in the table, two of which will have a matching machine name (38-DB2 in SAinCA's case). One of those two rows will have a NULL value in the SymmetricKey column. Deleting that row will remove the rogue "Waiting to Join" entry from your Scale-Out Deployment screen in SSRS Config Manager.

    • Marked as answer by SAinCA Friday, May 23, 2014 10:29 PM
    Thursday, May 22, 2014 2:16 PM
  • Thanks for updating this thread.

    It's bound to happen again when we upgrade to our next SQL Cluster, so I have this in my toolbox.

    Your solution appears to have worked for you, so I can at last mark this is answered, which will hopefully help others looking for the same answer.

    Cheers!

    Friday, May 23, 2014 10:29 PM