locked
Updating NRPT RRS feed

  • Question

  • Hi

    We have a live UAG setup with roughly 600 DirectAccess Clients using it.

    I need to make a change to the NRPT, however if I do this through the UAG console it removes the DirectAccess Group Policies and recreates them. If a client gets a group policy update during this period once they are removed, they lose connectivity and as such can't pick up the replacement policy to reconnect.

    As DA is connected as soon as there is a network connection, the only way I can think of to avoid this is to disconnect the external NICs for the UAG servers before making any changes and only reconnect once the new group policies are in place. Which isn't exactly ideal.

    Is there any issue with manually editting the Group Policies to add or remove the entry from the NRPT, rather than performing this action through the console.

    If I do make this change manually in the Group Policy will the details in the console reflect this?

    Is it just the UAG DirectAccess: Clients (servername.domainname.com) Policy that will require updating?

    If changing the settings this way is a bad idea and causes problems, is there another way of updating the NRPT without causing the Group Policies to be removed and recreated?

    Any help greatly appreciated.

    Thanks
    Chris

    Wednesday, October 24, 2012 12:00 PM

Answers

  • Not quite sure I understand why the updates break clients as the policices should essentially be identical apart from the additional NRPT entries?

    Have you done some form of non-standard GPO linking or something? Are the GPOs linked at the domain level and then blocked lower down or something?

    You can directly edit the GPO, but be aware than when you do re-run the UAG wizard in the future, it will reset them back to configuration stored in UAG unless you add them into the UI. Changes in the GPO will not be shown in the UAG console as the GPO is the result of a transform from configuration in the UAG console. Yes, the NRPT is in the client GPO.

    Once I understand why a UAG console change breaks it, I may be able to suggest some other options ;)

    Cheers

    JJ


    Jason Jones | Microsoft MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk


    Wednesday, October 24, 2012 11:14 PM

All replies

  • Not quite sure I understand why the updates break clients as the policices should essentially be identical apart from the additional NRPT entries?

    Have you done some form of non-standard GPO linking or something? Are the GPOs linked at the domain level and then blocked lower down or something?

    You can directly edit the GPO, but be aware than when you do re-run the UAG wizard in the future, it will reset them back to configuration stored in UAG unless you add them into the UI. Changes in the GPO will not be shown in the UAG console as the GPO is the result of a transform from configuration in the UAG console. Yes, the NRPT is in the client GPO.

    Once I understand why a UAG console change breaks it, I may be able to suggest some other options ;)

    Cheers

    JJ


    Jason Jones | Microsoft MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk


    Wednesday, October 24, 2012 11:14 PM
  • Hi

    Thanks for the reply.

    It's not that a change breaks it, it's that the process of the change causes problems. To clarify slightly, the installation is in a multi domain forest, with the UAG sat in the root domain and filtering down to sub domains. The group policies are based on group membership but linked to various OUs within the AD structure to avoid a few group policy break inheritance settings.

    When using the console you make the changes and click activate, at this point the previous Group Policies are deleted completely, once activation is complete (roughly 5 - 10 minutes later) a new group policy is created and placed in the root domain and then linked to the various domains with DA enabled. We then manually re link the new policies to the OUs which require them. During this process there are approximately 15 - 20 minutes when some parts of our AD structure have no DA group policy applying to them.

    Should a client perform a GPUPDATE during this period, it picks up that DA has been removed, if said Client is connected via DA, it disconnects and is therefore unable to pick up the new policies telling it to continue using DA with the new settings. As such the client then has to be physically brought to a location with LAN connectivity to get the policies reapplied.

    We have clients connected 24/7 so we find that whenever we perform an update we have this issue with 5 or so clients and it typically affects someone who's 200 + miles from an office with a LAN connection. Needless they're not best pleased with the need to drive 400 miles to get a connection. So a prefered option is to update the existing group policies without deleting and recreating.

    Thanks


    Chris

    Thursday, October 25, 2012 7:56 AM
  • It's not that a change breaks it, it's that the process of the change causes problems. To clarify slightly, the installation is in a multi domain forest, with the UAG sat in the root domain and filtering down to sub domains. The group policies are based on group membership but linked to various OUs within the AD structure to avoid a few group policy break inheritance settings.

    When using the console you make the changes and click activate, at this point the previous Group Policies are deleted completely, once activation is complete (roughly 5 - 10 minutes later) a new group policy is created and placed in the root domain and then linked to the various domains with DA enabled. We then manually re link the new policies to the OUs which require them. During this process there are approximately 15 - 20 minutes when some parts of our AD structure have no DA group policy applying to them.

    Should a client perform a GPUPDATE during this period, it picks up that DA has been removed, if said Client is connected via DA, it disconnects and is therefore unable to pick up the new policies telling it to continue using DA with the new settings. As such the client then has to be physically brought to a location with LAN connectivity to get the policies reapplied.

    Ah ok, that makes sense and yes, I have had a similar problem...it may be possible to modify the PS script output from the UAG console and then apply it manually to help?

    Jason Jones | Microsoft MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    Thursday, October 25, 2012 8:26 AM