AGMP 4.0 SP3 Client to Server Requirement Relative to Group Policy Extensions RRS feed

  • Question

  • Attempting to nail down a final design and looking for sign off from Microsoft and others in the community related to AGMP 4.0 SP3 and mixed OS environment and avoiding what I see is a potential risk/gap.  This post is long but necessary.  If you prefer short posts, this is not for you.  I'm simply trying to prevent / mitigate what I see as a risk and what I consider requirements to use this tool.

    At this point, I have read the AGMP Operations, Planning, and other Guides that come with the MDOP documentation bundle download.  Then I worked my way up Microsoft Docs for SP1, SP2, and SP3 so that I can properly assess and document previous to now existing functionality.  Forums. chapters on AGMP.  

    I cannot seem to find anything in official writing stating what for me, considering Group Policy Extensions, is a requirement to implement AGMP 4.0 SP3.  What I'm proposing might see extreme but I don't see away around it given the fact that GPE mismatch and then Central Repository on SYSVOL would result in gap or risk factor where unless that ADMX file (for example) is the same across all platforms you risk that policy working and errors client side trying to enforce group policies by operating system where some settings simply do not exist or incompatible with that version.

    Current customer has Windows 7, Windows 8.1, and I am preparing to kick off a migration to Windows 10.

    Please correct me if wrong.  To implement a fully functional AGMP 4.0 SP3 design you have three options.

    Option 1

    Install AGMP 4.0 SP3 server and client on: Server 2008R2 (Windows 7), Server 2012R2 (Windows 8.1), Server 2016 (Windows 10) 

    Any changes for corresponding Operating System the Requester would login to 1 of 3 servers.  Assumption too is that each server must coincide with the patch level of the client workstation or in Windows 10 case the "Current Branch".  

    Otherwise, the Group Policy Extensions compatibility is non-existent.  In other words, you cannot make changes for Windows 7 on 2012R2 server and expect it to work correctly when the central repository created on SYSVOL aligns more with Windows 8.1 GP Extensions.

    Option 2

    Install AGMP 4.0 SP3 server only on: Server 2008R2 (Windows 7), Server 2012R2 (Windows 8.1), Server 2016 (Windows 10) 

    Install AGMP 4.0 SP3 client only on: Windows 7, Windows 8.1, Windows 10 

    Spin up three virtual clients (my scenario - XenDesktop on ESXi 6.5), install prerequisites such as RSAT, .NET 4.6.2, WMF 5.1 (Powershell).  

    Each virtual client communicates to the corresponding server where GP Extensions align.

    Option 3

    Install AGMP 4.0 SP3 client and server on: Windows 7 SPX, Windows 8.1, Windows 10 virtual machines running on ESX and XenDesktop (VDI)

    Install prerequisites such as RSAT, .NET 4.6.2, WMF 5.1 (Powershell).  [Might as well use the latest stable version of .NET and WMF unless someone disagrees?)

    Windows 10 and 2016

    Based on the forum, I see where we have a possible issue with AGMP 4 SP3 installing on Windows Server 2016.  Of all the ones read, no answers.  If this is true, then installing server and client components on Windows 10 Enterprise Current Branch XXXX might be the only option.

    If not done this way, I fail to see how it would work 100%.  You must make changes to Group Policy from the Operating System where those policies must apply.  I fail to see why that would change with AGMP 4.  AGMP 4 SP3 simply added support for Windows 10 and Server 2016.  

    Which makes sense given the fact they have the same Group Policy Extensions, ADMX files, so forth.

    The customer expectation is one 2008R2 server, most clients are Windows 7.  So that works.

    Might break some things using Win 7 to 2008R2 for Win 8.1.  

    Definitely won't work for Windows 10 rollout.

    Can someone from Microsoft acknowledge the proposed design?

    Unless Windows 10, Server 2016 has all GP Extensions and supports all clients as Option 4.

    Where you have mix match of client OS and starting to spin up new workstations with Windows 10 and don't use this design you risk having a central repository that contains Group Policies that may or may not work on Windows 7, 8.1, and now 10.

    Brian Murphy

    Friday, December 15, 2017 3:56 PM

All replies

  • I have found the issue it is not anything related to the Pre - Req. Even the verbose logging gives incorrect error message.

    The issue is "DsWriteAccountSpn() failed. [ hr = 0x80072098 "Insufficient access rights to perform the 

    operation." ]"

    AGPM service account, only Domain admin/Enterprise admin/Administrators have permission to write its SPN attribute. Since SPN set is needed during AGPM-Server installation, it’s required that we run the installation wizard to ensure sufficient permission is provided.

    So I temporarily added the service account to Domain Admin and the setup worked without any issues.

    • Proposed as answer by DonPick Sunday, October 13, 2019 7:57 PM
    Wednesday, September 26, 2018 3:00 AM