Once of my colleagues asked me which Group Policy Client Side extensions (CSEs) get their Setting data in the Active Directory Group Policy Container (GPC) rather than SYSVOL's Group Policy Template (GPT).  From my research into the inner workings of Group Policies, the CSEs that I have found are as follows:

To complicate matters slightly, there are two CSEs that store their data in both the GPT and the GPC

All of the other CSEs have their data stored in SYSVOL's Group Policy Templates (GPT) folders.

I hope this helps someone else :)

Kindest Regards

Mark

CSEs.xlsx

Using Windows 8.1 and Outlook 2013 with Exchange

1. Go to the control Panel
2. Click User accounts
3. Click Manage Windows credentials
4. Click on the item that has the name Outlook in the title (something like MS.Outlook.15:<Email Address>
5. Click Edit
6. Change the password in here to the new Windows domain password
7. Click Save

This will inform Outlook what the new password is, hence why it keeps prompting for me to enter my password previously.

Simple when you know how!

Thankfully I found the fix.

I read on the internet that it could be a language issue, so I ventured onto TechNet.

1. I downloaded the Windows 8 Language pack "mu_windows_8_language_pack_x64_dvd_917544.iso"
2. I right clicked on the ISO and chose mount in the menu (which mounted the ISO to an available drive letter)
3. I right clicked the bottom left hand corner of my PC and ran "Command Prompt (Admin)"
4. I then typed in dism /online /add-package /packagepath:<Insert Mounted drive letter here>:\langpacks\en-us
5. Then I re-ran the installation and amazingly enough, it installed :):):)

NOTE: I did find the public version of the language pack https://windows.microsoft.com/en-us/windows-8/language#1TC=t1  you may be able to bypass this process, using the details held in this link, but I have not tried it.

I hope this helps someone else.

        I was just installing a InfoPath related package for InfoPath 2013, on Windows 8 and I ran into the following error:

Cannot create InfoPath.ExternalApplication object. Error code = 0x80080005

no matter what I did, I could not seem to get around it and there appears to be very little help on the internet for it.  I tried the following:

1. Run in Compatibility mode
2. Run in an elevated permission command prompt
3. Made sure I was a local admin
4. repaired InfoPath just in case it had an issue

None of the above fixed the problem.  I then saw a issue on TechNet relating to InfoPath "How to Use the Query Builder for View Filters and Advanced Searches" (https://support.microsoft.com/kb/307922) and figured I would give that a go.

I altered the reg key to match my version of office:

HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\

and created a sub key called "QueryBuilder"

When I restarted the installation of the InfoPath related package, it all installed and ran perfectly. So I thought I would make a note :)

Catch you later.

M

Just to remind myself, in order to enable GPO remote updates and remote policy logging, the required inbound firewall rules that needed to be enabled on the client are:

 I was looking for those hidden group policy schedule tasks that are created in Windows 8/2012 recently.  These tasks are the ones created to perform the routine Group Policy refresh updates and the administrator driven updates too (such as invoke-GPUpdate in powershell).

So just so as I can remember (plus you may find them useful too)

They are located here:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\Microsoft\Windows\GroupPolicy\

The default tasks are sub keys called:

{3E0A038B-D834-4930-9981-E89C9BFF83AA}

{A7719E0F-10DB-4640-AD8C-490CC6AD5202}

These are for the user and computer default refresh.

Any manual updates will be stored in separate folders underneath called the GroupPolicy Key, these will be called:

GPUpdate

GPUpdate (<user>@<domain>)

Of course, the GPUpdate key will have the computer refresh value and the GPUpdate (<user>@<domain>) will be the user refresh :)

        Something must be wrong with me, as I am posting more than normal on my blog!.  This time its about Windows 8.  I have rebuilt my PC over the last few evenings and been running into the error:

"We couldn't create a new partition or locate an existing one.  For more information, see the Setup log files."

This error hits after you enter the CD key (I must have entered mine about 30 times trying to get around this issue), when you try to assign the partition that you wish to install windows 8 on.  I have 3 hard drives in my PC and I have tried all numerical combinations of disks, plus unplugged all USB ports (I didnt have any devices in my PC during install), removed all SD ports (I didnt have anything in them anyway) and removed anything else that was not screwed on.  Still the same error.

I finally fixed it by following this process (IMPORTANT: These steps assume that you have not got any data on any of your HDDs that you care about!!!):

Reboot the PC with the Win 8 CD in and select repair

Head over to the advanced tools option

once in the command prompt run Diskpart

Type LIST DISK

Type SELECT DISK <whatever disk number you have> 

Type CLEAN

Type CREATE PARTITION PRIMARY

Type ACTIVE

Type FORMAT FS=NTFS QUICK

Type ASSIGN

perform the above for any other hdds present, but dont make any other drive active of course.

Now reboot and start in the installation over again.  you should be good to go :)

I hope this helps you

    I just thought that I would finally post a little something about WQL (WMI Query Language) queries for Group Policies.  It is regularly observed by most of my customers that examples of WMI queries for GPOs are found here: https://technet.microsoft.com/en-us/library/cc758471(v=ws.10).aspx#CommunityContent . 

It is important to note that these are examples and are not optimized by any means, they are there to provide the various options to filter policies from machines/users that match certain criteria.  If you are looking to implement a WMI query, the first thing I would suggest is to ask yourself this "Can we use preferences and item level targeting instead?" If the answer is no, then implementing WMI filters are not an issue, as long as you stick to these simple guidelines:

1. WMI queries are not saved in the GPC or GPT and are not backed up using the Group Policy management console by default
2. The first WMI query that your client executes as part of GPOs, will add approximately 1 second onto the boot up time, although this will get slightly faster with each GPO with a WMI query.
3. WMI queries should be optimized to select the exact content that you want, for example:  Select * from Win32_POTSModem Where Name = " MyModem" could be made more efficient by changing the query to Select Name from Win32_POTSModem Where Name = " MyModem"
4. Windows XP and beyond (at least to Win 8), the default answer from a WMI failure is negative.  So if you are asking " are you Windows 7" and the WMI engine has an issue on that machine, it will respond "No"
5. Make sure that WMI is functional on your client machines  by monitoring them.  WMI services can be damaged by rogue code/applications/Hardware drivers.  I have to spend a lot of my time fixing WMI issues on customer sites.

Just a few thoughts and ramblings to get you started :)

RODCs require a special flag on their connection objects for SYSVOL replication to work. If not present, SYSVOL will not work for FRS or DFSR. To fix these servers:

1. Logon to a writable DC in the affected forest as an Enterprise Admin.

2. Run DSSITE.MSC and navigate to an affected RODC within its site, down to the NTDS Settings object. There may be no connections listed here, or there may be manually created connections.

3. Create a new connection object. Ideally, it will be named the same as the default (ex: "RODC Connection (FRS)").

4. Edit that connection in ADSIEDIT.MSC or with DSSITE.MSC attribute editor tab. Navigate to the "Options" attribute and add the value of "0x40".

5. Create more connections using these steps as necessary.

6. Force AD replication outbound from this DC to the RODCs, or wait for convergence. When the DFSR service on the RODC sees these connections, SYSVOL will begin replicating again.

More info about this 0x40 flag: https://msdn.microsoft.com/en-us/library/dd340911(PROT.10).aspx

RT (NTDSCONN_OPT_RODC_TOPOLOGY, 0x00000040): The NTDSCONN_OPT_RODC_TOPOLOGY bit in the options attribute indicates whether the connection can be used for DRS replication [MS-DRDM]. When set, the connection should be ignored by DRS replication and used only by FRS replication.

Despite the mention only of FRS in this article, the 0x40 value is required for both DFSR and FRS. Other connections for AD replication are still separately required and will exist on the RODC locally.

If you’re running Windows 8, you can get it from the Windows Store here:

https://aka.ms/sposterpedia

thanks Martin (aka the poster guy :)

https://blogs.technet.com/b/theposterguy/