Azure Site Recovery Communications

%3CLINGO-SUB%20id%3D%22lingo-sub-738747%22%20slang%3D%22en-US%22%3EAzure%20Site%20Recovery%20Communications%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-738747%22%20slang%3D%22en-US%22%3E%3CP%3EI%20have%20an%20Azure%20Site%20Recovery%20configuration%20server%20connected%20to%20a%20Vmware%20environment%20that%20appears%20to%20be%20having%20some%20communications%20issues%20that%20we%20cannot%20identify.%26nbsp%3B%20I'm%20looking%20for%20some%20input%2Fadvice%20please%20on%20what%20we%20should%20be%20doing%20next%20to%20resolve%20our%20issue.%26nbsp%3B%20There%20appears%20to%20be%20communication%20between%20the%20vault%20and%20the%20configuration%20server%2C%20or%20there%20was%2C%20until%20last%20Friday%20when%20the%20Azure%20Recovery%20Services%20agent%20was%20updated%20and%20the%20server%20was%20rebooted.%26nbsp%3B%20Following%20the%20instructions%20I%20go%20into%20Protected%20Items%20and%20select%20Replication%20Items%20and%20pick%20a%20vm%20to%20click%20the%20Update%20Agent%20button%2Foption%20but%20none%20exists.%26nbsp%3B%20I%20see%20this%20under%20the%20details%20for%20the%20configuration%20server%3A%3C%2FP%3E%3CP%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-inline%22%20style%3D%22width%3A%20999px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Fgxcuf89792.i.lithium.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F122239iE2EE3CCC953C0BAD%2Fimage-size%2Flarge%3Fv%3D1.0%26amp%3Bpx%3D999%22%20alt%3D%22Untitled%20picture.png%22%20title%3D%22Untitled%20picture.png%22%20%2F%3E%3C%2FSPAN%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-inline%22%20style%3D%22width%3A%20999px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Fgxcuf89792.i.lithium.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F122237iB6C2F2856D192E10%2Fimage-size%2Flarge%3Fv%3D1.0%26amp%3Bpx%3D999%22%20alt%3D%222019-07-04-%20Microsoft%20Azure.png%22%20title%3D%222019-07-04-%20Microsoft%20Azure.png%22%20%2F%3E%3C%2FSPAN%3E%3C%2FP%3E%3CP%3EThe%20last%20heartbeat%20shows%20April%20but%20I%20have%20last%20heartbeat%20results%20at%20the%20top%20of%20the%20page%20that%20tell%20me%2028%20June.%26nbsp%3B%20We%20have%20checked%20firewalls%2C%20etc%20and%20all%20of%20the%20ports%20required%20are%20open.%26nbsp%3B%20Any%20suggestions%20or%20places%20I%20might%20look%20to%20narrow%20down%20what's%20happening%3F%26nbsp%3B%20Any%20help%20is%20much%20appreciated.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-738747%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAzure%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EAzure%20Site%20Recovery%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-738905%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20Site%20Recovery%20Communications%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-738905%22%20slang%3D%22en-US%22%3E%3CP%3EAny%20chance%20we%20could%20get%20the%20logs%20from%20the%20configuration%20server%20from%20within%20VMware%3F%26nbsp%3B%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F77013%22%20target%3D%22_blank%22%3E%40Mitch%20Sprague%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-750246%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20Site%20Recovery%20Communications%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-750246%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F183000%22%20target%3D%22_blank%22%3E%40Bryan%20Haslip%3C%2FA%3EThanks%20for%20responding%20Bryan%20and%20apologies%20for%20not%20responding%20sooner.%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20were%20able%20to%20determine%20the%20issue%20is%20related%20to%20this%20registry%20key%3A%3C%2FP%3E%3CP%3EHKEY_LOCAL_MACHINE%5CSYSTEM%5CCurrentControlSet%5CControl%5CLsa%5Cfipsalgorithmpolicy%3C%2FP%3E%3CP%3EThe%20value%20is%20set%20to%201.%3C%2FP%3E%3CP%3EChanging%20to%20value%20to%200%20allows%20the%20communication%20process%20to%20begin%20functioning%20again%20properly.%26nbsp%3B%20I'm%20waiting%20to%20get%20the%20original%20reference%20to%20this%20from%20my%20colleague%20and%20I'll%20post%20it%20here%20when%20I%20do.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-750588%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20Site%20Recovery%20Communications%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-750588%22%20slang%3D%22en-US%22%3E%3CP%3EI%20am%20glad%20to%20hear%20it%20is%20resolved!%20Thank%20you%20for%20updating%20us%20with%20the%20fix.%26nbsp%3B%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F77013%22%20target%3D%22_blank%22%3E%40Mitch%20Sprague%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E
Highlighted
Occasional Contributor

I have an Azure Site Recovery configuration server connected to a Vmware environment that appears to be having some communications issues that we cannot identify.  I'm looking for some input/advice please on what we should be doing next to resolve our issue.  There appears to be communication between the vault and the configuration server, or there was, until last Friday when the Azure Recovery Services agent was updated and the server was rebooted.  Following the instructions I go into Protected Items and select Replication Items and pick a vm to click the Update Agent button/option but none exists.  I see this under the details for the configuration server:

Untitled picture.png2019-07-04- Microsoft Azure.png

The last heartbeat shows April but I have last heartbeat results at the top of the page that tell me 28 June.  We have checked firewalls, etc and all of the ports required are open.  Any suggestions or places I might look to narrow down what's happening?  Any help is much appreciated.

3 Replies
Highlighted

Any chance we could get the logs from the configuration server from within VMware? 

@Mitch Sprague 

Highlighted

@Bryan HaslipThanks for responding Bryan and apologies for not responding sooner. 

We were able to determine the issue is related to this registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\fipsalgorithmpolicy

The value is set to 1.

Changing to value to 0 allows the communication process to begin functioning again properly.  I'm waiting to get the original reference to this from my colleague and I'll post it here when I do.

 

Highlighted

I am glad to hear it is resolved! Thank you for updating us with the fix. 

@Mitch Sprague