Thursday, April 7, 2022

Managing Group Policy ADMX Files Step-by-Step Guide

 

Some Important Factors about the Implications of ADMX Files in Your Environment

  • New Windows Vista-based or Windows Server 2008-based policy settings can only be managed from Windows Vista-based or Windows Server 2008-based administrative machines running Group Policy Object Editor or Group Policy Management Console. Such policy settings are defined only in ADMX files and, as such, are not exposed on the Windows Server 2003, Microsoft Windows XP, or Windows 2000 versions of these tools.
  • The Windows Vista or Windows Server 2008 versions of Group Policy Object Editor and Group Policy Management Console can be used to manage all operating systems that support Group Policy (Windows Vista and Windows Server 2008, Windows Server 2003, Windows XP, and Windows 2000).
  • The Windows Vista or Windows Server 2008 versions of Group Policy Object Editor and Group Policy Management Console support interoperability with versions of these tools on early operating systems. For example, custom ADM files stored in GPOs will be consumed by the new tools.
  • In the majority of situations, you will not notice the presence of ADMX files during your day-to-day Group Policy administration tasks.

ADMX Technology Review

In Windows Vista, ADMX files are divided into language-neutral and language-specific resources, available to all Group Policy administrators. These factors allow Group Policy tools to adjust their UI according to the administrator's configured language. Adding a new language to a set of policy definitions is achieved by ensuring that the language-specific resource file is available.

Comparison of ADM and ADMX Local File Locations

In Windows Vista beta 2, the operating system–defined Administrative Template policy settings will only install on the local computer as an ADMX file format.

ADMX files will be installed on each Windows Vista computer in a different file location from ADM files, as shown in the following table.

(Custom ADM files can still be copied to the listed ADM directory to be consumed by the Group Policy Object Editor and Group Policy Management Console.)

File Type File Location
ADM %systemroot%\inf
ADMX language neutral (.admx) %systemroot%\policyDefinitions
ADMX language specific (.adml) %systemroot%\policyDefinitions\[MUIculture] (for example, the U.S. English ADMX language specific file will be stored in %systemroot%\policyDefinitions\en-us)

ADMX Domain File Locations

One of the main benefits of using the new ADMX files is the central store. This option is available to you when you are administering domain-based GPOs, although the central store is not used by default. In Windows Vista and Windows Server 2008, the Group Policy Object Editor will not copy ADM files to each edited GPO—the case with earlier operating systems. Instead the Group Policy Object Editor will no longer copy the new ADMX files, but will provide the ability to read from either a single domain-level location on the domain controller sysvol (not user configurable) or from the local administrative workstation when the central store is unavailable. This capability reduces the amount of storage needed for files that should remain constant for all GPOs. In addition to storing the ADMX files shipped in the operating system in the central store, you can share a custom ADMX file by copying the file to the central store, which makes it available automatically to all Group Policy administrators in a domain.

File Type Domain Controller File Location
ADMX language neutral (.admx) %systemroot%\sysvol\domain\policies\PolicyDefinitions
ADMX language specific (.adml) %systemroot%\sysvol\domain\policies\PolicyDefinitions\[MUIculture] (for example, the U.S. English ADMX language-specific file will be stored in %systemroot%\sysvol\domain\policies\PolicyDefinitions\en-us)

Requirements for Editing Group Policy Objects with ADMX Files

The following sections describe specific computer setups required for editing either the local GPO or domain-based GPOs with ADMX files. This step-by-step guide assumes you understand the basic concepts of Group Policy and using the Group Policy Management Console.

Local Group Policy Object Editing Requirements

While editing the local GPO, you must use a Windows Vista-based computer to view policy settings from ADMX files.

Domain-Based Group Policy Object Editing Requirements

In order to be able to create and edit domain-based GPOs with the latest Group Policy settings using ADMX files, you must have this setup:

  • A working Windows Server 2008, Windows Server 2003, or Windows 2000 domain using name resolution through a DNS server.
  • A Windows Vista computer to view policy settings from ADMX files while editing the domain-based GPO.

ADMX Scenarios

The scenarios in this document are designed to introduce you to managing ADMX files for Group Policy editing. (Group Policy editing refers to the process in which you create a GPO or open an existing GPO and then change policy settings using the Group Policy Object Editor). The following two scenarios illustrate how the Group Policy Object Editor will transparently incorporate ADMX files into an editing session. The domain-based scenario shows you how to centrally manage ADMX files, a feature that was not available with ADM files.

Scenario 1: Editing Local Group Policy Object Administrative Template Settings

Editing a local GPO introduces you to ADMX files that are transparently included when opening the Group Policy Object Editor. The way you edit Administrative Template policy settings and the way the settings are displayed remains unchanged from previous versions of Windows.

Scenario 2: Editing Domain-Based Group Policy Object Administrative Template Settings

Editing a domain-based GPO introduces you to optional central store for ADMX files in a domain and how to edit GPOs using this central store.

Scenario 1: Editing the Local GPO with ADMX Files

This scenario shows you how ADMX files are transparently incorporated into editing the local Group Policy.

Editing the Administrative Template Policy Settings of the Local GPO with ADMX files

You must use a Windows Vista-based computer to edit local GPOs using ADMX files.

To edit administrative template policy settings using ADMX files

  1. To open the local Group Policy Object Editor on a Windows Vista machine, click Start, click Run, then type GPEDIT.msc.
  2. The Group Policy Object Editor will automatically read all ADMX files stored in the %systemroot%\PolicyDefinitions\ folder.
  3. Locate the policy setting you wish to edit and open it.

Note   You can still remove and add ADM files to the GPO using the Add/Remove Templates menu option. There is no user interface for adding or removing ADMX files in Windows Vista.

To add ADMX files to the Group Policy editing session, copy the ADMX files to the %systemroot%\PolicyDefinitions\ folder and restart the Group Policy Object Editor.

Scenario 2: Editing Domain-Based GPOs with ADMX Files

This scenario shows you how to set up a central location of the updated ADMX files when managing domain-based Group Policy from Windows Vista–based computers.

Prerequisites for Administering Domain-Based GPOs with ADMX Files

To complete the tasks in this section, you should have at least:

  • A Windows Server 2008, Windows Server 2003, or Windows 2000 domain utilizing a DNS name server.
  • A Windows Vista-based computer to use as an administrative workstation.

Steps for Utilizing the Optional ADMX Central Store with Domain-Based GPOs

If you choose to not create an ADMX central store, editing GPOs will work the same way as in Scenario 1: Editing the Local GPO with ADMX Files. To edit GPOs using centrally stored ADMX files, complete these tasks in order.

Create a Central Store

The central store is a folder structure created in the sysvol directory on the domain controllers in each domain in your organization. You will need to create the central store only once on a single domain controller for each domain in your organization. The File Replication service then replicates the central store to all domain controllers. It is recommended that you create the central store on the primary domain controller because the Group Policy Management Console and Group Policy Object Editor connect to the primary domain controller by default.

The central store consists of a root-level folder containing all language-neutral ADMX files and subfolders containing the language-specific ADMX resource files.

To perform this procedure, you must be a member of the Domain Admininstrators group in Active Directory.

To create the central store

  1. Create the root folder for the central store %systemroot%\sysvol\domain\policies\PolicyDefinitions on your domain controller.

  2. Create a subfolder of %systemroot%\sysvol\domain\policies\PolicyDefinitions for each language your Group Policy administrators will use.

    Note   Each subfolder is named after the appropriate ISO-style Language/Culture Name. For a list of ISO-style Language/Culture Names, see Valid Locale Identifiers. For example, to create a subfolder for U.S. English, create the subfolder: %systemroot%\sysvol\domain\policies\PolicyDefinitions\EN-US

Populate the Central Store with ADMX Files

There is no user interface for populating the central store in Windows Vista. The procedure shows how to populate the central store using command line syntax from the Domain Controller.

To populate the central store

  1. Open a command window: click Start, click Run, then type cmd.

  2. To copy all the language-neutral ADMX files from your Windows Vista administrative workstation to the central store on your domain controller using the xcopy command, type:

    xcopy %systemroot%\PolicyDefinitions\* %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\

  3. To copy all ADMX language resource files from your Windows Vista administrative workstation to the central store on your domain controller using the xcopy command, type:

    xcopy %systemroot%\PolicyDefinitions\EN-US\* %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\EN-US\

Edit the Administrative Template Policy Settings in the Domain-Based GPOs

You can edit GPOs only using ADMX files on a Windows Vista-based computer.

To edit administrative template policy settings using ADMX files

  1. To open the Group Policy Management Console on a Windows Vista machine, click Start, click Run, then type GPMC.msc.
  2. To create a new GPO to edit, right-click the Group Policy objects node and select New.
  3. Type a name for the GPO and click OK.
  4. Expand the Group Policy objects node.
  5. Right-click the name of the GPO you created and click Edit.
  6. The Group Policy Object Editor automatically reads all ADMX files stored in the central store. When there is no central store, the Group Policy Object Editor reads the local versions of the ADMX files used by the local GPO on your Windows Vista administrative machine.

Note   You can still remove and add ADM files to the GPO. There is no user interface for adding or removing ADMX files in Windows Vista.

To add local ADMX files to the Group Policy editing session, copy the ADMX files to the %systemroot%\PolicyDefinitions\ folder and restart the Group Policy Object Editor.

PRI vs. SIP Trunking: What's the Difference?

 

PRI vs. SIP Trunking:

Primary Rate Interface (PRI) is an interface standard used to deliver multiple voice lines over physical copper lines that are part of your building’s physical infrastructure. Session Initiation Protocol (SIP) trunking is a set of technical standards that support VoIP calls by initiating and ending calls between a VoIP line and the PSTN.

What is PRI Phone Service?

PRI is a T-1 transmission technology that has been widely used to support voice communications for over 40 years.

A PRI circuit includes 23 voice channels to support 23 concurrent calls, and one data channel to support call-related functionality like caller ID. Voice calls that are supported through PRI technology are submitted as electrical pulses and routed through traditional telecommunications carriers. Traditional telephony requires a relationship with a telecommunications company and on-site servicing of cabling to add lines or upgrade equipment.

PRI is an alternative to IP-based phone technologies, including SIP trunking.

Pros of PRI

  • Does not rely on data bandwidth to support voice calls
  • High quality via dedicated line structure
  • Can be made redundant via the addition of a second PRI circuit for failover

Cons of PRI

  • PRI is expensive to implement and upgrade and requires costly monthly phone service
  • May require long-term contracts with traditional telecom companies for local and long-distance calling
  • Requires dedicated capacity that can only be purchased in 23 line units
  • Slow to scale, modifications to infrastructure may take weeks of waiting.

Best Uses Cases for PRI Technology

  • Organizations with legacy PRI infrastructure and limited access to fiber-optic internet connectivity or sufficient bandwidth to support IP-based phones.
  • Hybrid PRI and SIP trunking implementations, where organizations retain legacy PRI technology for local calls while using SIP for multimedia communications and saving costs on long-distance/international calling.

 

What is SIP Trunking or a SIP Phone?

SIP supports the transmission of voice calls as data as well as other types of multimedia communications. SIP is a phone technology, but it supports the transmission of Unified Communications, including video conferencing, SMS messages, data transmissions, and more.

For organizations with hosted phone communications, SIP trunking equipment is generally hosted and maintained by the vendor to manage the transmission of voice data. SIP is an alternative to PRI in that it completely eliminates the need for traditional phone infrastructure, including circuits.

Pros of SIP Trunking

  • Sold by vendors on a per-channel basis on-demand, so you only pay for the capacity needed.
  • Much cheaper; cost savings vary but can be as much as 30-40% cheaper than PRI phones
  • Offers failover to mobile phones in case of loss of office data connectivity
  • Includes easy-to-use administrative portals for easy management
  • May be offered via the cloud as part of a Unified Communications (UC) implementation
  • Can be integrated with multimedia communications for collaboration and productivity
  • Offers simple support for multiple sites and remote workers
  • May include rich mobile features and mobile-first design
  • Integrates with PRI phone lines for hybrid phone systems

 

Cons of SIP Trunking vs. PRI

  • Requires internet bandwidth, ideally business fiber internet, to support quality of service (QoS).
  • Needs sufficient network information security, like firewalls, to prevent cybercrime risks.
  • The quality and extensibility of service offered by hosted VoIP vendors can significantly vary

Best Use Cases for SIP Technology

  • Saving money on business phone service, especially for organizations with long-distance and international outbound calling.
  • Cost-effective support for contact centers.
  • Adding mobility features to the enterprise and supporting remote workers.
  • Reducing the burden of phone system management on internal IT personnel.
  • Moving towards hosted, multi-channel cloud communications or Unified Communications as a Service (UCaaS)
  • Gaining the ability to quickly scale business communications by adding and removing lines and features on-demand.

Is PRI vs. SIP Trunking Best for My Business?

PRI and SIP Trunking are competing approaches to phone technology that carry distinct advantages and disadvantages.

For many organizations, SIP trunking to support VoIP telephony or UCaaS is the smarter choice and enables access to the benefits of significant cost savings, improved collaboration tools, and better reliability.

For other firms, a hybrid approach to using both PRI and SIP is the right decision. Educational institutions may decide to implement Unified Communications, but maintain a few PRI lines to support legacy intercom technology and some disaster recovery planning scenarios. For other businesses still, PRI may be the right choice.

Head to Head: PRI vs. SIP on 4 Key Business Considerations

1. Cost

For the vast majority of organizations, SIP is much cheaper than PRI. Cost is an important consideration for organizations, even though it’s not the only factor to take into account when you’re investing in a business phone system. Organizations that need to scale their system, add features, and perform long-distance calling are likely to achieve massive cost savings.

There are very rare instances where PRI may be less costly than SIP. These use cases are generally limited to small, brick-and-mortar businesses with no need for advanced phone features like eFax or integrated messaging. For organizations that are not going to grow or adopt different communication technologies, maintaining an existing PRI system could be the right choice.

Who wins? SIP Trunking most of the time.

2. Information Security

PRI is considered more secure, which isn’t strictly correct. Copper cabling can be subject to a number of information security risks, including interference and interception. However, organizations that lack on-site information security expertise to achieve adequate network security and attempt to run consumer-class VoIP over public internet connectivity may be very vulnerable to security risks.

Who wins? SIP Trunking with adequate network security.

3. Flexibility

The biggest con to PRI is also among the greatest pros of SIP trunking; flexibility and scalability. With PRI, organizations are required to purchase additional user capacity in 24 lines. With SIP, organizations can add a line for a service month to accommodate a temporary or seasonal employee, and remove the line as soon as it’s no longer needed. SIP can enable organizations to unlock truly usage-paid billing on-demand, while organizations using PRI may need to wait weeks to schedule a technician for very high-cost infrastructure upgrades.

Who wins? SIP Trunking.

4. Reliability

The reliability of copper-based phone cabling can be damaged through a number of risks, including inclement weather, vandalism, or simple degradation of an aging infrastructure. While PRI is considered a very reliable technology, and it generally is, organizations will lose access to phone service if a component of their infrastructure is damaged.

SIP is reliable, provided organizations partner with a reliable vendor and invest in fiber-optic internet connectivity which is very resistant to weather and other common types of damage. With mobile failover, organizations can continue using dedicated phone lines even if there is a loss of data connectivity on site.

Who Wins? It depends. Generally, SIP wins, but some organizations may prefer a hybrid approach.

Choosing Between PRI vs. SIP Trunking

Is PRI or SIP trunking the best choice for your business? Ultimately, that depends on your organization, your goals, and your desire to adopt next-generation communication and collaboration features. The majority of organizations today have adopted or plan to switch to VoIP phones and UCaaS as a tool for cost savings, better value, and business agility. While PRI is the right choice for some select organizations, many firms find that SIP beats out traditional PRI phones.