When we install Office 2010 we have to go in and change settings in each program. These include access to our network (Trusted Locations), our templates location (File Locations), enabling macros (Macro settings), and Client Settings.

We install as the administrator then set these options. When we log off and put the computer into service, those settings have to be reset for the next person who logs in.

This is a problem because sometimes we can't get back to the computer in question to reset these settings making it useless.

How do we get these settings to hold for ALL USERS of one computer without using Group Policy? We've tried that and it's way too confusing. There are not enough instructions to set it up and it's not explained in the Active Directory classes. I took them.

Any help would be greatly appreciated.

Thanks,

Jessica

You can customize your installation fileset, by using the OCT, and the guidance here for that:
https://technet.microsoft.com/en-us/library/ee460874(v=office.14).aspx

Using that method, when you perform installation of Office, your customized settings are applied to that computer, and will be applied to users of that computer thereafter (but as a preference, so each user can change as desired).

If you use an Active Directory domain, and your users all use domain logon accounts on domain member (joined) workstations, you can use domain Group Policy (admin templates). This method means that you don't need to visit each computer to deploy the settings. It also means that users can't fiddle with the settings easily.

You can use local Group Policy, but that's about the same effort at each PC, compared to manually applying the settings.

If you don't have people who roam around using different or multiple computers, or you don't change/refresh/replace computers often, Group Policy (either local or domain) is less return for the effort.

[AD classes don't usually cover admin templates for Office, which is a shame, because it's a very common scenario and a great example of the power of domain Group P

Thank you, Don, for the link and advice.

I just don't understand it. We don't do enough on a daily basis for me to understand Group Policy or how to set it up. We ran on Novel for so long that this is just all too confusing. We didn't have separate users on the computers. Everyone logged in as User. They only logged into the network with different user names and that didn't effect the setup of the computer.

I'm thinking at this point that there is no way to just configure settings for all users without using Group Policy. Is that correct?

I do appreciate your help though.

Thanks,

Jessica

I am coming to the conclusion that I wouldn't be so confused if things were actually explained instead of Microsoft thinking we are all Einstein and can just figure this out.

Yes, I'm frustrated.

I followed the link you provided above - Customize the installation for Office 2010 - https://technet.microsoft.com/en-us/library/ee460874(v=office.14).aspx.

From there I went to Customizer setup for Office 2010 - https://technet.microsoft.com/en-us/library/ee656736(v=office.14).aspx.

From there I went to - Configure user settings for Office 2010 - https://technet.microsoft.com/en-us/library/cc178990(d=printer,v=office.14).aspx.

I have downloaded the OCT files. I have them stored on the network on the same location as the Office 2010 installation files. This is where the confusion comes in. Please help me through this because it does not make any sense.

"In Office 2010, two architecture-specific versions of the Office Customization Tool (OCT) are available: one for 32-bit Office 2010 and one for 64-bit Office 2010. The 64-bit version of the OCT supports 64-bit client editions of Office 2010, and provides the same user interface, capabilities, and configurable settings as the 32-bit version. You use the same command to run the 32-bit or 64-bit version of the OCT. For instance, if you want to run the 32-bit OCT, run the setup.exe /admin command line from the x86 (32-bit) folder as shown in the following example: \\server\share\Office14\x86\setup.exe /admin. To run the 64-bit OCT, run the setup.exe /admin command line from the x64 (64-bit) folder. For more information about 64-bit Office 2010, see 64-bit editions of Office 2010."

"

To configure user settings

1. To start the OCT, from the root of the network installation point, type the following at the command prompt: setup.exe /admin."

Where is this information coming from??? I have the setup files for Office but they do not let me configure any "User" settings. I am thinking this is not the file they want me to look for, but there is no explanation here. 

Any ideas??

Thanks,

Jessica

There also are not any setup.exe files that were downloaded with OCT. I show a AdminTemplates_32.exe or _64.exe. If I run these they are like Zip files and extract to wherever I tell them to extract to.

I extracted them to a folder called Extract (to make it simple) within the same directory. In the extract I have 2 folders ADM, Admin, ADMX. 

ADM contains access14.adm type files for all of the office programs. No setup files.

Admin contains access14.opax and access14.opal type files, again for all of the office programs. No setup files.

ADMX contains access14.admx and access14.adml type files, again for all of the office programs. No setup files.

Am I missing something?

Thanks,

Jessica

Does Office need to be installed on Active Directory for this to work?

Thanks,

Jessica

The OCT is actually a builtin component of the setup.exe for Office (but it's only builtin to Volume License editions of Office e.g. ProfessionalPlus or Standard, OCT is not included in Retail editions of Office e.g. Professional, H&B, etc)

So if you're using a VL edition of Office, you already have the OCT bits. The download is only really needed if you have a need to customise a Retail edition, or, to get the Admin Template files. Admin Template files are used if you want to control settings etc via Group Policy.

The OPAX and OPAL files are used by the OCT (setup.exe) to perform customisation of the setup/installation (to generate an MSP file, which is applied at setup time).

The ADM files are used for older WindowsOS versions (e.g. WinXP or WS2003), for Group Policy settings.

The ADMX/ADML files are used for newer WindowsOS versions (e.g. Vista/2008 and newer) for Group Policy settings.

So, are you using a domain (Active Directory) ?

Are you using a VL edition of Office on your workstations ?

: when you install Office on a machine, you will run setup.exe, which is the installation bootstrapper.
If you run "setup.exe /admin", this tells the Office installer that instead of installing Office, you want to launch the OCT to create a customisation file.

Ok - that makes sense. 

Yes I am using a domain (Active Directory).

Yes we have a VL edition of Office. We use the MAK key instead of the KMS, but that shouldn't matter right?

I installed office on Active Directory hoping maybe that would help me but it didn't. I'm going to uninstall it.

So I need to run the actual setup.exe file that came from Office - from a dos prompt?

I will update in a minute.

Thank you for all your help.

You're AWESOME!!!

It's starting to make sense.

Thanks,

Jessica

Yes, the documentation is bewildering, especially if you've never worked with customising Office before, and more so if you're not familiar with Group Policy.

This page explains a bit more about customisation, and has a couple of videos which might help:
https://technet.microsoft.com/en-us/library/cc179097(v=office.14).aspx

(There was a lot more content, for Office 2007. Most of that content still applies for Office2010 and Office2013. As crazy as it sounds, you might find the Office2007 content better to learn on, since MSFT wrote that content to explain the all-new-OCT)

I have set a few things up in Group Policy. Simple things like a time server policy to keep the computers synced and an admin policy giving certain users admin rights so they can access our ERP software on the server. For some reason that was blocked and the users all had to be admins. Whatever makes it work.

So I ran the OCT and the only thing I was really able to setup in it was adding the MAK key and telling it to auto activate.

It won't let me add our server as a trusted location, i can add it after the fact but that defeats the whole purpose of this.

So now that I kind of figured this part out, what about this part? - https://technet.microsoft.com/en-us/library/cc179081(v=office.14).aspx

When I follow these steps I can create the GPO, I can link the GPO, but there is nothing to edit. I right-click and select Edit. Under Computer Configuration I select Policies - Administrative Templates - All Settings, which says "There are no items to show in this view."

So I still can't set up the GPO. What am I missing?

Thanks,

Jessica

I have set a few things up in Group Policy. Simple things like a time server policy to keep the computers synced and an admin policy giving certain users admin rights so they can access our ERP software on the server. For some reason that was blocked and the users all had to be admins. Whatever makes it work.

So I ran the OCT and the only thing I was really able to setup in it was adding the MAK key and telling it to auto activate.

It won't let me add our server as a trusted location, i can add it after the fact but that defeats the whole purpose of this.

So now that I kind of figured this part out, what about this part? - https://technet.microsoft.com/en-us/library/cc179081(v=office.14).aspx

When I follow these steps I can create the GPO, I can link the GPO, but there is nothing to edit. I right-click and select Edit. Under Computer Configuration I select Policies - Administrative Templates - All Settings, which says "There are no items to show in this view."

So I still can't set up the GPO. What am I missing?

Thanks,

Jessica

Are you using Windows 7?
Did you follow the guide at https://technet.microsoft.com/en-us/library/cc179081(v=office.14).aspx to copy the ADMX and ADML files to C:\Windows\PolicyDefinitions ?

If so, when you execute gpedit.msc (the Local Policy Editor), the various Office Admin Templates should automatically be populated in the Administrative Templates "node" of the editor.

Select the specific template for the specific Office application (e.g. Access) and expand/navigate down through:
\Microsoft Access 2010\Application Settings\Security\Trust Center\Trusted Locations\

You should see: "Allow Trusted Locations on the Network" and "Trusted Location #1, #2, etc"

This is Win8.1/Office2013, but it's very similar:

I am using Windows Server 2008 R2 with Active Directory. We have a separate Server 2008 R2 that just runs and stores all our "stuff". Then we have 2 Windows Server 2008 R2 with Active Directory. They replicate each other in the case of one going down.

Yes, I did follow that guide and I copied the ADMX files to c:\windows\sysvol\domain\policies\policydefinitions\en-us.

I didn't think I needed the language folder as we only use one language but they didn't show up when I had them in policy definitions so I created the en-us folder and moved them there. They still don't show up in GPMC. The way you show it drilled down above, I only have Administrative Templates - All Settings. There are no other folders under Administrative Templates.

Thanks,

Jessica

ok, if you didn't previously have anything residing at c:\windows\sysvol\<FQDN>\policies\policydefinitions, that means that you didn't have a Central Store for templates (which is fine).

Note that in the MSFT example they show \sysvol\domain\policies, but what that really means is \sysvol\YOUR-FQDN\policies.

e.g. if my domain is named contoso.com, the path for me would be:
c:\windows\sysvol\contoso.com\policies\policydefinitions\

Note that you don't have to use the Central Store method, but, if you do, you must copy all existing ADMX/ADML files, in the correct locale/language subfolders, into the CS.

This is because, when a CS is present/detected, the c:\windows\policydefinitions\ folder on the machine executing GPMC will be ignored in favour of the CS.

So, check the folder path you created on the sysvol.

If you didn't quite get it right (due to the FQDN piece), that's ok, this just means that you haven't properly implemented CS and the improper path is being ignored, so, the local c:\windows\policydefinitions\ folder is being used.

In that case you can choose to copy the Office ADMX/ADML into the local policydefinitions folder, and the Office templates will then show up in GPMC.

Or you can correctly implement CS, copy *ALL* templates including the Windows ones into the CS, and GPMC will be fine.

Note that if you did want to pursue the non-AD-GPO methods (as per my example screenshot), you would need to copy the templates into c:\windows\policydefinitions of every computer where Office will beinstalled, and then configure the desired settings in gpedit.msc on every computer. which would be very tedious :(

CS references

http://support.microsoft.com/kb/929841 

http://blogs.technet.com/b/askpfeplat/archive/2011/12/12/how-to-implement-the-central-store-for-group-policy-admin-templates-completely-hint-remove-those-adm-files.aspx

http://deployhappiness.com/creating-the-group-policy-central-store-updated-for-windows-8-12012r2/

Ok I didn't understand when I first copied the files into domain\policies but after looking around I noticed that it replicated itself into the proper folder. Or maybe that was supposed to happen, I don't know, but I have those ADMX files in c:\windows\sysvol\sysvol\contoso.com (our domain name)\policies\policydefinitions\ and when I deleted them from where I did put them, they deleted from here also, so I put them back. LOL

So I found this online - https://technet.microsoft.com/en-us/library/cc709647(d=printer,v=ws.10).aspx

In the Community Additions section half-way down there is this information:

--------------------------------------------

Office ADMX files.

One thing I ran across when trying to use admx files was a lack of information on the requirements for the central store.
The main thing I wanted to accomplish was managing Office 2007 with group policy. After following instructions for creating the PolicyDefinitions folder, and copying all of my admx/adml files into the folder, I had lost all of the default policy settings under Administrative Templates like Control Panel and System.
If you create the central store, you have to copy Server 2008 adminstrative template files into the folder. You cannot simply copy the Office 2007/2010 admin templates, or the only thing that will be listed under Administrative Templates is your office settings. Once the central store is created, GPME will only display settings from that store.
You can get the Server 2008 R2 and Windows 7 Administrative Templates from the following location:
http://www.microsoft.com/downloads/en/details.aspx?familyid=16F69FFE-D51B-4E02-9D02-3E57F3CCD490&amp;amp;amp;amp;displaylang=en
By default this installs adml files for 54 additional languages you may want to remove to reduce replication traffic. These language files are close to 145MB.
Once you've copied both sets of Adminstrative templates into the central store, you will be able to manage both Windows and Office.

--------------------------------------

I downloaded that file but haven't done anything with it. Is it needed? It is the same as the files that are already in c:\windows\policydefinitions? Because if I look in c:windows\policydefinitions there are a bunch of ADMX files.  This is what you are talking about. I should copy these over to c:\windows\sysvol\sysvol\contoso.com (our domain name)\policies\policydefinitions\

What about policies that are already there? I shouldn't lose them by making any of these changes should I?

 

I do not want to do this computer by computer. I am sticking with Group Policy from Active Directory. I will learn this. I so appreciate your help. 

Thank you,

Jessica

Sorry I posted that before I saw your second post. I am going through those documents now. :)

Thanks,

Jessica

I downloaded that file but haven't done anything with it. Is it needed? It is the same as the files that are already in c:\windows\policydefinitions? Because if I look in c:windows\policydefinitions there are a bunch of ADMX files.  This is what you are talking about. I should copy these over to c:\windows\sysvol\sysvol\contoso.com (our domain name)\policies\policydefinitions\

What about policies that are already there? I shouldn't lose them by making any of these changes should I?

When you first create the CS folders on SYSVOL, they are empty, but the mere existence of the CS will force GPMC to defer to the CS to look for templates. This is why you need to place a copy of all the Windows templates plus whatever Office/other templates in the CS.

It's simplest to copy the Windows (and any other templates) from c:\windows\PolicyDefinitions into the CS - you don't specifically need to use that download files set of Windows templates.

Once you've established your CS, you can then consider if you need to download newer Windows template files (e.g. the newer templates to suit newer Windows edition features), just replace any existing files in the policydefinitions folder with the newer versions.

Note that in general, Windows templates are not Windows-version-specific, but Office templates *ARE* version specific, so if you need to have settings from the Office2010 templates, and say you also needed to use settings from the Office2013 templates, you need both sets of templates to cater for both version of Office. (they are different filenames for the Office templates)

Also note that templates are what defines the available settings, but templates don't contain the actual GPOs/policies in your domain. When you author a GPO and into that GPO you open a template and enable a setting, the actual setting, and the values you assign to the setting, are actually written into the GPO (the GPO is stored in a different place in SYSVOL/AD, it's not stored in the policydefinitions folder at all)

This is similar in concept to a Word template compared to a Word document, i.e. the template doesn't contain your document content.

And yes, SYSVOL is replicated across all of your domain controllers, which is how the templates CS is deemed to be "central", because it's placed once and then replicated around for you.

And, don't use ADM files in your CS - the CS is only used for ADMX/ADML files. (ADM files are the pre-Vista form of templates).
ADM files, if placed in your CS, won't work, and they just waste space on SYSVOL.