7 Replies Latest reply on Nov 9, 2010 9:53 AM by gill.brewer

    Change FQDN and Public IP of Gateway

    Silvercoupe Apprentice

      In the next few weeks I will be required to modify our LDMG's fully qualified domain name and public IP address.  The Gateway sits in our DMZ with a single NIC setup (was not allowed dual NICs for security reasons).  Does anyone have a quick checklist available of what all needs to be done to ensure devices will continue to connect via the LDMG?  I'm assuming it's something like:

       

      1.  Modify the LDMG with the new FQDN

      2.  From Core server console> Configure>Management Gateway> Enter new information> restart service?

       

      At this point, I'm not sure what the best way would be to deploy this new configuration to our clients.  Any thoughts would be appreciated.

       

       

      Side note, can anyone tell me how to get rid of the cert from my old core server?  It shows up as the cert in the Configure Management Gateway wizard as well as all my agent configurations.  I only want the new cert deployed in our environment so I'd like it to be gone as that cert came over during the migration to LD9 (side by side).

       

      Thanks.

        • 1. Re: Change FQDN and Public IP of Gateway
          cknott SupportEmployee

          Mike, when the clients get a gateway certificate the .0 file on the agent is modified and the IP address of the Management Gateway is added.  If the IP address of the gateway changes, then the clients will be hard coded to a bad address and will not be able to create the SSL tunnel to establish a session with the gateway.

           

          If you absolutely have to change the public IP address of the Gateway, then you need a way to update the client certificates.  You can have them manually run brokerconfig, but that option kind of sucks if you have a lot of users.

           

          I wrote an autoit script that will update the .0 file that can be pushed out through a policy or a push.

           

          http://community.landesk.com/support/docs/DOC-7348

           

          Hopefully this helps.

          1 of 1 people found this helpful
          • 2. Re: Change FQDN and Public IP of Gateway
            Silvercoupe Apprentice

            Thanks for the response Chad.

             

            Yeah, it's unfortunate but we do have to change our Public IP.  When I first installed the LDMG a few years ago, I actually used Security and Patch and a Custom Definition to run brokerconfig.exe -r.  I created a definition that looked for the existence of the 3 files in the \cbaroot\broker folder.  If they did not exist I ran brokerconfig.exe -r.  Since I had no machines outside the Gateway at that point it worked great.  I'd love to be able to use that again after making the changes, but I think it would just get messy.

             

            Thanks for the AutoIT script.  I tried to get it working and when I run the script on my test box the modified date of the .0 file is changed, telling me that the script did something, but when I run brokerconfig.exe the IP address is still the same.  If I create the broker.conf.xml (I commented that section out earlier for troubleshooting), brokerconfig.exe shows the new FQDN in both the "Management Gateway" fields, one under each tab.  I guess that would be OK for remote control but I do not see the IP address changing to reflect the new Public IP.

             

            Any ideas where this may be going wrong?  I like this approach as I can use a policy to automate the install to my clients, but so far I'm not having any luck getting the IP to change in brokerconfig.

            • 3. Re: Change FQDN and Public IP of Gateway
              Silvercoupe Apprentice

              Update:

               

              The BrokerIP field within the .0 file did in fact change when I ran the AutoIt script.  It's just not being reflected when I run brokerconfig.exe and look at the tabs.  Is this normal behavior?  I figured brokerconfig would read from this .0 file when it displays the gateway information.  The .0 file was changed to reflect the new IP, but it seems the broker.conf.xml file supercedes whatever you put in there?  Or is that only for remote control?

               

              Thanks again.

              • 4. Re: Change FQDN and Public IP of Gateway
                cknott SupportEmployee

                Mike, did you restart the remote control service after running the autoit script?    Yes, the broker.conf.xml is used for gateway remote control.  When you start a gateway remote control, the client reads the broker.conf.xml for where it should go.  In the .0 file the IP address is used to build the secure tunnel with the gateway.

                • 5. Re: Change FQDN and Public IP of Gateway
                  Silvercoupe Apprentice

                  I just tried that.  The .0 file is definitely being updated with the new BrokerIP but even after restarting the remote control service when I run brokerconfig.exe I don't see the new IP address anywhere.  It still shows the old IP of the gateway.  Now granted, I haven't actually made the change to the gateway service on the core yet, I'm still in planning mode.

                   

                  Where is brokerconfig.exe reading that information from, and by information I mean from the 2 tabs that state "Management Gateway"?  When I add the broker.conf.xml the information definitely changes when I look at brokerconfig.exe, but then both fields state the FQDN that I specify in the AutoIt script.  Maybe this is working as intended?  Based on what you're saying I guess I'm good as long as the .0 file has the correct BrokerIP but I'd feel a lot better if I actually saw that IP show up in brokerconfig.exe.

                  • 6. Re: Change FQDN and Public IP of Gateway
                    Silvercoupe Apprentice

                    Another quick question.  If I were to make the changes to the LDMG and the Gateway service on the Core, then push out a new agent configuration and run brokerconfig.exe -r, the new changes would already be reflected, correct?  I know this would not work for units outside the LDMG, but at this point I'm not too concerned.  Most of our units check in at least once every few weeks on the local LAN so they could be updated at that point.

                     

                    I'm thinking of going this way since it would make it very easy to identify the devices which still needed the new LDMG info.  Besides the overhead of deploying a new agent, is there any reason this would not work?

                    • 7. Re: Change FQDN and Public IP of Gateway
                      Rookie

                      We've had a similar situation in that we are in the middle of a side by side upgrade of both our Landesk core and the Management Gateway which needed to be deployed to about 1000 machines across 60 sites outside our main network.

                      Getting it all working was quite a battle.

                      In the end, I modified the agent ini to delete the old certificates, include a broker.conf.xml file and used the brokerConfig.lng workaround to run brokerconfig.exe with the correct credentials to pull a new certificate.

                       

                      The relevant part of the agent ini file is as follows:

                       

                      WCDELETE100003=%SYSTEM%\cba\Broker\*
                      FILE100001=BrokerConfig.lng, %PROGRAMFILES%\LANDESK\SHARED FILES\cbaroot\Broker\brokerConfig.lng
                      FILE100002=broker.conf.xml, %PROGRAMFILES%\LANDESK\SHARED FILES\cbaroot\Broker\broker.conf.xml
                      EXEC10001=Brokerconfig.exe, /r, INSTALLONLY