Service accounts are dead. Long live MSAs! But where can you actually use MSAs/gMSAs? One place that often pops up is Advanced Group Policy Management (AGPM) from the Microsoft Desktop Optimization Pack (MDOP).

The installer for AGPM requires that you create a service account and enter its password manually. In a correctly configured AGPM GPO environment, no one will have access to edit the GPOs except this account. So knowing its password is a bad thing. But how can we get past the installer, so we can run AGPM using an MSA/gMSA?

Here’s how. Note this isn’t an official endorsement. I did this in my lab and it works fine. I checked with a few trusted colleagues and they think it’s fine too. If you really are moving away from manual service accounts, then try this out in your lab. You’ve now been warned.

There are 2 scenarios:

1. A fresh install of AGPM
2. An existing install of AGPM

The steps are almost identical. I’ll call out the differences as we go though the core steps.

1. Create the KDS rootkey for gMSAs if one doesn’t exist in the forest:

• Only needed if using gMSAs in Windows Server 2012 or later AND the key hasn’t already been created

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

2. Create a gMSA called gMSA-AGPM$ with samaccountname = gMSA-AGPM$

3. Create a temporary user account (for use during AGPM installation) called svc-AGPM (if AGPM is already installed, you skip this step)

4. Assign both svc-AGPM and gMSA-AGPM$ “Logon as a Service” right on the AGPM server.

• Note that this right may be defined a GPO, so local policy changes may be ignored. Set this right on the PO if needed.

5. Install AGPM using svc-AGPM (if AGPM is already installed, you skip this step)

6. Once the installation is done, stop the service “AGPM Service”

7. Remove the ServicePrincipalNname (SPN) for AGPM from the AD users ‘svc-AGPM’ and place it on gMSA-AGPM$ instead

8. Set the registry value at HKLM\Software\Microsoft\AGPM\ArchiveOwner to have the SID of gMSA-AGPM$

• Use psgetsid.exe from Sysinternals to convert a username to a SID

9. Set the permissions on the AGPM data folder (by default this is C:\ProgramData\Microsoft\AGPM) and on the folder %windir%\temp to grant ‘Full Control’ on these 2 folders and all sub files and folder to gMSA-AGPM$

10. Set permissions on all GPOs to grant gMSA-AGPM$ full control using:

Set-GPPermission -All -PermissionLevel GpoEditDeleteModifySecurity -TargetName CONTOSO\gMSA-AGPM$ -TargetType Computer

11. Set permissions to the root of each domain to all gMSA-AGPM$ to have “Link GPO” rights to all OU objects:

$agpmserviceaccountname = “gMSA-AGPM$”

$domaindn = (Get-ADDomain).distinguishedname

$agpmaccountsid = (get-adserviceaccount $($agpmserviceaccountname)).sid

$newsddl = "(OA;CI;RPWP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;;$($agpmaccountsid))"

$objsecurity = get-acl -Path "ad:\$($domaindn)"

$objsecurity.SetSecurityDescriptorSddlForm($objsecurity.sddl+$newsddl)

Set-Acl -Path "ad:\$($domaindn)" -AclObject $objsecurity

12. Remove all other accounts as having Editor rights to all GPOs.

• Take care with this step in production as many files ACLs will be changed causing SYSVOL to re-replicate all data. Also, when you are removing permissions you may also accidentally remove “Apply GPO” and “Read” rights where they have been specifically set as a way of targeting GPOs to specific users, groups and computers.

13. Add gMSA-AGPM$ as a member to the AD group “Group Policy Creator Owners” and “Backup Operators”

14. Install the Service Account gMSA-AGPM$ as a managed account on the AGPM server using this cmdlet:

  Install-ADServiceAccount -Identity gMSA-AGPM$

• Note that you will need the feature for AD PowerShell Module installed first to run the cmdlet Install-ADAccount

15. Set service properties for AGPM Service to logon as CONTOSO\gMSA-AGPM$ (keep the password fields blank)

16. Start the service “AGPM Service”

17. Remove “Logon as a Service” right for the temporary account svc-AGPM

18. Delete/disable the account svc-AGPM in the domain

19. Delegate rights in AGPM to domain users/groups to be admins/editors/approvers/reviewers as normal in AGPM

20. Delegate “Link GPO rights” for OUs to Admins in AD as normal

Ned Pyle, the Product Manager for Storage Replica, has written a great “getting started” guide here:

https://social.technet.microsoft.com/Forums/windowsserver/en-US/f843291f-6dd8-4a78-be17-ef92262c158d/getting-started-with-windows-volume-replication?forum=WinServerPreview

I got mine going after adding the Windows Storage Replication feature in Server Manager:

It’s configured in Failover Clustering:

·        The existing 2003 DFS server is FILE1. All the commands below are run on this server in C:\temp.

·         The first new 2012 R2 DFS server is FILE2

·         The domain is child.corp.contoso.com

·         The DFS Namespace in the domain is called “Testing”, so the path is \\child.corp.contoso.com\Testing

·         There are 3 target servers where all DFS links point to: TARGET1 , TARGET2 , TARGET3

Hi,

Pat Fetty recently blogged about the new SCM baselines for Office 2013 going live.

I opened up my local copy of SCM and imported the content:

The .cab file contains the security settings. The “att” file contains the attachments which are Word documents describing the security baseline settings.

You may get prompted at this point to accept the security details of the package. Inspect the certificates to make sure they are issued by Microsoft and are trusted by your computer.

There are user and computer settings, separated by individual Office programs or core Office settings.

Done!

Browsing these new settings looks like this:

Once you export these settings into a GPO Backup and import them onto an existing blank GPO in your domain, you’ll want the ADMX/ADML files which relate to the Office 2013 settings. And you’ll probably want to save them into your PolicyDefinitions folder in SYSVOL:

\\your.domain.name\SYSVOL\your.domain.name\Policies\PolicyDefinitions

Get theme here:

https://www.microsoft.com/en-us/download/details.aspx?id=35554

I’ve just finished working on a case with a customer that was so interesting that it deserved a blog post to round it off.

These were the symptoms:

Often while logged in to the server things would appear to freeze – no screen updates, little mouse responsiveness, if you could start a program (perfmon, Task Manager, Notepad etc.) then you wouldn’t be able to type into it and if you did it would crash.

This Windows Server 2008 R2 server runs TSM backup software with thousands of servers on the network sending their backup jobs to it. At any one time there could be hundreds of backup jobs running. The load was lower during the day, but it was always working hard dealing with constant backups of database snapshots from servers. The backup clients are Windows, UNIX, Solaris, you name it…

When the server froze, you’d see 4 of the 24 logical CPUs lock at 100% and the other 20 CPUs would saw-tooth from locking at 100% to using 20-30%. The freeze would happen for minutes at a time.

There are 2 Intel 10GB NICs in a team using Intel's teaming software. The team and the switches are setup with LACP to enable inbound load balancing and failover.

By running perfmon remotely before the freeze happens we could see that the 4 CPUs that are locked at 100% are locked by DPCs. We used the counter “Processor Information\% DPC Time”.

A DPC is best defined in Windows Internals 6th Ed. (Book 1, Chapter 3):

Because this is a backup server, we’re expecting that the bulk of our hardware DPCs will be generated by incoming network packets and raised by the NICs. Though they could have been coming from the tape library or the storage arrays.

To look into what exactly is generating DPCs and how long the DPCs last for, we need to run Windows Performance Toolkit, specifically WPR.exe (Windows Performance Recorder). We have to do this carefully. We don’t want to increase the load of the server by capturing the Network and CPU activity of a server which already has high activity on the CPU and Network, and has shown a past history of crashing. But we want to run the capture while the server is in a frozen state. A tricky thing. So we ran this batch file:

Start /HIGH /NODE 1 wpr.exe -start CPU –start Network -filemode –recordtempto S:\temp

ping -n 20 127.0.0.1 > nul

Start /HIGH /NODE 1 wpr.exe –stop S:\temp\profile_is_CPU_Network.etl

If the server you are profile has a lot of RAM (24GB or more), you’ll want to protect your non-paged pool from increasing and harming your server. To do that you should review this blog and add this switch to the start command: –start "C:\Program Files (x86)\Windows Kits\8.0\Windows Performance Toolkit\SampleGeneralProfileForLargeServers.wprp"

We’re starting on NUMA node 1 as the NICs were bound to NUMA node 0 and the “Processor Information” perfmon trace we took earlier showed that the CPUs on NUMA node 0 were locked. We’re starting the recorder with a “high” prioritization so that we can be sure it gets the CPU time it needs to work. We’re not writing to RAM, we’re recording to disk in the hopes that if the trace crashes we’ll at least have a partial trace to use. We made sure that S: in this example was a SAN disk to ensure it had the required speed to keep up with the huge data we’re expecting. We’re pinging 20 times to make sure our trace is 20 seconds long. And finally we’re starting a trace of CPU and Network profiles.

Note that to gather stacks we first had to disable the ability for the Kernel (aka the Executive) to send its own pages of memory out from RAM to the pagefile, where we cannot analyze them. To do this run wpr –disablepagingexecutive on and then reboot.

We retrieved 3 traces in all:

1. The first trace to diagnose the problem
2. The second trace after 2 changes were made which generated about 50% of our problem
3. The final trace after the final change was made which created the other 50% of the problem

Diagnosis

So this blog now becomes a short tutorial on how you can use WPA (Windows Performance Analyzer) to locate the source of DPC issues. WPA is a VERY powerful tool and diagnosing problems is part science, part art. Meaning that no two diagnosis are ever done in the same way. This is just how I used WPA in this case. For this analysis, you’ll need the debugging tools installed and symbols configured and loaded.

CPU Usage (Sampled)\Utilization By CPU

First I want to see which CPUs are pegged. For that we use “CPU Usage (Sampled)\Utilization By CPU”, then select a time range by right-clicking:

Choose a round number (10 seconds in my example) as it makes it easier to quickly calculate how many things happened per minute when comparing to the graphs for the later scenarios:

I chose 20 seconds to 30 seconds as it is a 10 second window where there was heavy load and not blips due to tracing starting or stopping. Then “Zoom” by right clicking again.

Now all your graphs will be focused on that time range.

Then shift-select the CPUs which are pegged. In this case it is CPUs 0, 2, 4 and 6. This is because the cores are Hyperthreaded and the NICs cannot interrupt a logical CPU which is the result of Hyperthreading (CPUs 1, 3, 5, 7 etc.). And they are low-numbered CPUs because they are located on NUMA node 0.

Once they are selected, right-click and choose “Filter to Selection”:

Next we want to add a column for DPCs so we can see how much of the CPUs time was spent locked processing DPCs. To add columns, just right click on the column title bar (in the screen above this has “Line # | CPU || Count | Weight (in view) | Timestamp”) on the centre of the right hand pane and select the columns you want to display. Once the DPC/ISR column has been added, drag it to the left side of the yellow bar, next to the CPU column:

Expanding out the CPU items, we see that DPCs count for almost all of the CPU activity on these CPUs (the count figures for the CPUs activity is 10 seconds of CPU time and the count of CPU time for DPCs under this is over 9 seconds).

DPC duration by Module, Function

The next WPA graph we need is the one which can show how long the DPCs last for. We drag in the first graph under “DPC/ISR” called “DPC duration by Module, Function”:

One the far right column (“Duration”), we can see how long each module spends waiting with a DPC. This says that 36.8 seconds were spent on DPCs for NDIS.SYS alone. How can it be 36.8 seconds if the sample window is 10 seconds? Well, it is CPU seconds, and we have 24 CPUs, so we could potentially have 240 CPU seconds in all.

The next biggest waiter for DPCs is storport.sys. But at 1 second, it’s not even close.

The column with the blue text is called “Duration (Fragmented) (ms) Avg” and is the average time a DPC lasts for during this sample window. The NDIS.SYS DPCs last around 0.22 milliseconds, or 220 microseconds. The count of DPCs for NDIS and storport are comparatively similar (163,000 and 123,000 respectively), but because NDIS took so long on each DPC on average, it ended up locking the CPU for longer than storport did.

So let’s add the CPU column, move it to the left side of the yellow line with it as the first column to pivot on:

We can see that our targeted CPUs, 0, 2, 4. 6 have very high durations of DPC waits (using the last column for “Duration”, again) with no other CPU spending very much time in a DPC wait state. So we select these CPUs and filter.

Expanding out the CPUs, we see that there are many different sources of DPCs, but that NDIS is really the biggest source of DPC waits. So we will now move the “Module” column to be the left-most column and remove the CPU column from view. We then right click on NDIS.SYS and “Filter to Selection” again as we only want to focus on DPCs from NDIS on CPUs 0, 2, 4, 6:

One function, ndisInterruptDPC is causing our DPC waits. This is the one we’ll focus on. If we expand this, it will list every single DPC and how long that wait is. Select every single one of these rows by scrolling to the very bottom of the table (in this example there are 163,230 individual DPCs):

Right click on the column called “Duration” and choose “Copy Other” and then “Copy Column Selection”. This will copy only the values in the “Duration” column. We can paste this into Excel and create a graph which shows the duration of the DPCs as a function of the number of DPCs present:

I have added a red line on 0.1 milliseconds because according the hardware development kit for driver manufacturers, a DPC should not last longer than 100 microseconds. Meaning DPC above the red line are misbehaving. And that this is the bulk of our time spent waiting on DPCs.

So, we have established that we have slow DPCs on NDIS, and lots of them, and that they are locking our 4 CPUs. Our NICs aren’t able to spread their DPCs to any other CPUs and Hyperthreading isn’t really helping our specific issue. But what is causing the networking stack to generate so many slow DPC locks?

DPC/ISR Usage by Module, Stack

The final graph in WPA will show us this. From the category “CPU Usage (Sampled)”, drag in a graph called “DPC/ISR Usage by Module, Stack”. Filter to DPC (which will exclude ISRs) and our top candidates are:

1. ntoskrnl.exe (the Windows Kernel)
2. NETIO.SYS (Network IO operations)
3. tcpip.sys (TCP/IP)
4. NDIS.SYS (Network layer standard interface between OS and NIC drivers)
5. IDSvia64.sys (Symantec Intrusion Detection System)
6. ixn62x64.sys (Intel NIC driver for NDIS 6.2, x64)
7. iansw60e.sys (Intel NIC teaming software driver for NDIS 6.0)

To see what these are doing we simply expand the stack columns by clicking the triangle of the row with the highest count, looking for informative driver names and a large drop in the number of counts present, indicating that this particular function is causing a consumption of CPU time.

NTOSKRNL is running high because we are capturing. The kernel is spending time gathering ETL data. This can be ignored.

NETIO is redirecting network packets to/from tcpip.sys for a function called InetInspectRecieve:

TCP/IP is dealing with the NETIO commands above to do this “Receive Inspection”:

NDIS.SYS is dealing with 2 main functions in tcpip.sys: TcpTcbFastDatagram and InetInspectRecieve again:

Other than ntoskrnl, these 3 Windows networking drivers all have entries for the drivers listed as 5, 6 and 7 above in their stacks.

Diagnosis Summary

Lots of DPCs are caused by 3 probable sources:

1. Incoming packet inspection by the Symantec IDS system.

1. The IDS system has to take every packet, compare it to a signature definition, and, if clean, allow it to pass. This action is causing slow DPCs

• The NIC driver could be stale/buggy and generating slow DPCs.

1. There is no evidence for this, but it’s usually a good place to start. There could be TCP offloading or acceleration features in the NIC and/or driver which haven’t been enabled but may improve network performance.

• And finally the NIC teaming software is getting in between the NICs and the CPUs.

1. That is, after all, the job of the NIC teaming software: to trick Windows into thinking that the incoming packets from 2 distinct hardware devices are actually coming from 1 device. The problem here, however, is that this insertion into the networking stack is pure software, but is likely causing very slow DPCs

Action Plan

Our actions were to make changes over 2 separate outage windows:

1. Update the NIC driver and enable Intel I/OAT in the BIOS of the server.

1. I/OAT is described in the spec sheet for the NIC like this: “When enabled within multi-core environments, the Intel Ethernet Server Adapter X520-T2 offers advanced networking features. Intel I/O Acceleration Technology (Intel I/OAT), for efficient distribution of Ethernet workloads across CPU cores. Load balancing of interrupts using MSI-X enables more efficient response times and application performance. CPU utilization can be lowered further through stateless offloads such as TCP segmentation offload, header replications/splitting and Direct Cache Access (DCA).”

• Uninstall the NIC teaming software

1. 3rd party NIC teaming software inhibits many TCP offloading features, and in this case generates large numbers of slow DPCs

• On the second outage we uninstalled the IDS system.

1. IDS was not configured on this (and all other) servers. But as the software had the potential to become enabled, it was grabbing every incoming packet for inspection, despite the fact that it wasn’t configured to inspect the packet or act on violations in any way. Stopping the service is insufficient, the driver must be removed from the hidden, non-plug and play section of the device manager. Manually removing the driver isn’t sufficient. The software will reinstall it at next boot. Only a full uninstall will do.

After dissolving the NIC Team

Here is what the picture looked like after we dissolved the NIC team, updated the NIC driver and enabled Intel I/OAT in the BIOS.

In this 10 second sample we can see that the 4 CPU cores are still effectively locked as the CPU time due to NDIS DPCs is 37.7 seconds (out of a possible maximum of 40 seconds. The number of DPCs has decreased by more than half to 55,000, meaning that the average duration of DPCs has become very long at 682 microseconds – triple the average time from before we removed the NIC team and enabled I/OAT.

The blue area of the graph above is the picture we had from before changes were made. The pink/orange area is the picture of DPC durations after removing NIC teaming and enabling I/OAT.

So why did the average duration of DPCs get longer?

It could be that the IDS software now does not need to relinquish its DPCs to make room on the same CPU cores as the DPCs for the NIC teaming driver. These 2 drivers must be locked to the same CPUs. With no need to relinquish a DPC due to another DPC of equal priority, the IDS DPCs are free to use the CPU for longer periods of time before being forced off.

At any rate, it certainly isn’t fixed yet.

After uninstalling Symantec IDS

And finally here’s what the picture looked like after we uninstalled the IDS portion of the Symantec package. Remember, this service was not configured to be enabled in any way.

You can see that the average time has dropped from 220 microseconds to 90 microseconds – below the 100 microsecond threshold required by the Driver Development Kit.

In this 10 second sample there were 127,000 DPCs from NDIS on the 4 heavily used CPUs, but the CPU time they consumed was 11 seconds, a reduction from 36.8 seconds.

The blue area of the graph above is the picture we had from before changes were made. The pink/orange area is the picture of DPC durations after removing NIC teaming and enabling I/OAT. And the green area is the picture after IDS is removed.

This is a dramatic improvement. Nearly all DPCs are below the 100 microsecond limit. The system is able to process the incoming load without locking up for high priority, long lasting DPCs.

What about RSS?

We’re not quite done though. 4 of our CPUs are still working very hard, often pegged at 100%. But why only 4? This is a 2-socket system with 6 cores on each socket. That gives us 12 CPUs where we can run DPCs. DPCs from one NIC are bound to one NUMA node. We already dissolved our NIC team, so we only have 1 NIC in action, so we are limited to 6 cores. RSS can spread DPCs over CPUs in roots of 2, meaning 1, 2, 4, 8, 16, 32 cores. Meaning we can at most use 4 CPUs per NIC.

To scale out we would need to add more NICs and limit RSS on each of those NICs to 2 cores. We’d need to bind 3 NICs to NUMA node 0 and 3 to NUMA node 1. We’d also need to set the starting CPUs for those NICs to be cores 0, 2, 4, 6, 8 and 10. In that we can saturate every possible core.

But to do this, we’d need to ensure that we can have multiple NICs, without using the teaming software. Which means we’d need to assign each NIC a unique IP address. To do that we need to make sure that the TSM clients can deal with targeting a server name with multiple IP addresses in DNS for that name. And if connectivity to the first IP address is lost, that TSM can failover to one of the other IP addresses. We’ll test TSM and  get back with our results later.

But we need one more fundamental check before doing that: We need to make sure that the incoming packet, hitting a specific NUMA node and core is going to end up hitting the right thread of the TSM server where that packet is going to be dealt with and backed up. If we can’t align a backup client to the incoming NIC and align that NIC to the backup software thread that should process it, then we’ll be causing intra-CPU interrupts, or worse yet, cross NUMA interrupts. This would make the entire system much less scalable.

So this is how this would all look. The registry key to set the NUMA node to bind a NIC to is “*NumaNodeId” (including the * at the start). To set the base CPU, use *RssBaseProcNumber”. To set the maximum number of processors to use set “*RssBaseProcNumber”.

These keys are explained here: https://msdn.microsoft.com/en-us/library/windows/hardware/ff570864(v=vs.85).aspx

and here: Performance Tuning Guidelines for Windows Server 2008 R2

And more general information on how RSS works in Windows Server 2008 are here: Scalable Networking- Eliminating the Receive Processing Bottleneck—Introducing RSS

Our problem in the above picture, however, is that our process doesn’t know to run its threads on the NUMA node and cores where the incoming packets are arriving. Had this been SQL server, we could have run separate instances configured to start using specific CPUs. Hopefully, one day, TSM will operate like this and become NUMA-node aware.

I know this has been a long post, but for those who have read down to here, I do hope this has helped you with your troubleshooting using WPT.

I have been helping a customer with a tricky issue recently regarding slow network performance for SMB file copies over their network.

It came about after they took the settings defined in Security Compliance Manager for their member servers and deployed them as a Group Policy to their server OU. After doing this, they saw an 80% reduction in the performance in SMB file copies. But when we used Ntttcp.exe to test the network throughput via a test data stream, the throughput was not affected. Only SMB was affected.

They had Windows Server 2008 R2 SP1 VMs on ESX with 1 virtual 10Gb NIC patched to a team of 2 physical 10Gb NICs. When 2 servers tried to copy a set of large test files without the SCM security settings applies, they could reach around 400Mbps. When we applied the settings, that dropped to around 80Mbps

In the SCM security definitions, there are 234 settings defined. We had to find out which one of these settings caused their issue.

We could see that the CPUs of the VM were going nuts with a wild saw-tooth pattern of all CPUs. We tried adding more CPUs and the saw-tooth pattern simply spread without making any major change in achievable throughput.

The process consuming the CPU time in Task Manager was ‘System’.

So, to break into ‘System’ a little more, we ran Windows Performance Recorder (WPR) to get a trace of CPU activity, like this:

And in the trace, we expanded out “CPU Usage (Sampled)”, and added the graph for “DPC and ISR by Module, Stack”:

This showed us that all our CPU time was spent processing DPCs generated by a driver called cng.sys

This is “Kernel Cryptography, Next Generation” which relates to the server or clients ability to calculate cryptographic equations in the Kernel when doing things like sending or receiving encrypted information, or information which has been signed. Signing in this case could be creating a signature hash for chunks of transmitted data to prove that is hasn’t been modified while on the wire.

This, combined with the fact that only SMB was affected lead us to think it was SMB signing that was our issue.

SMBv2 uses these 2 GPO settings to define SMB signing:

1. Microsoft Network Server: Digitally sign communications (always)
2. Microsoft Network Client: Digitally sign communications (always)

The settings relate to SMBv2. Note that they change the default, in-box setting from “Disabled” to the Microsoft recommended SCM setting of “Enabled”.

For SMBv1 on Windows 2003 and older, the GPO settings are:

1. Microsoft Network Server: Digitally sign communications (if client agrees)
2. Microsoft Network Client: Digitally sign communications (if server agrees)

Once we removed the “always” settings, the transfer speed returned back to the higher 400Mbps transfer speed we expected.

We discussed the usefulness of this setting and in their network, it would be best to keep the “server” side setting enabled on DCs only to ensure that the GPO files which clients will download from the DCs during a Group Policy refresh have not been altered as these files are security sensitive files, but are usually very small and we don’t mind slightly slower transfer speeds for these files.

Here’s some additional resources we used when investigating SMB signing:

https://blogs.technet.com/b/josebda/archive/2010/12/01/the-basics-of-smb-signing-covering-both-smb1-and-smb2.aspx

https://msdn.microsoft.com/en-us/library/a64e55aa-1152-48e4-8206-edd96444e7f7#id218

https://blogs.msdn.com/b/openspecification/archive/2009/07/06/negtokeninit2.aspx?Redirected=true

https://blogs.msdn.com/b/openspecification/archive/2009/04/10/smb-maximum-transmit-buffer-size-and-performance-tuning.aspx

https://blogs.technet.com/b/filecab/archive/2012/05/03/smb-3-security-enhancements-in-windows-server-2012.aspx

https://support.microsoft.com/kb/320829

https://blogs.technet.com/b/neilcar/archive/2004/10/26/247903.aspx

https://gallery.technet.microsoft.com/NTttcp-Version-528-Now-f8b12769

I recently had the pleasure to help one of our Premier customers with a query they have regarding saving images in Active Directory.

Default Permission in AD

By default, users have permission to save a jpeg or bmp file to their own AD user account. This file can be up to 100KB in size. In a large AD with hundreds of thousands of users, this could quickly increase the size of the AD database. The increase in size can increase backup times, increase the backup size and slow down restores.

This permission is granted via the constructed security principal, “SELF”.

“SELF” is given permission to a set of attributes, not to the individual attributes themselves. By combining attributes into groups of common attributes, you reduce the size of the ACL entry. These groups are called Permission Sets. The attributes which relate to images are:

• Picture (aka thumbnailPhoto)
• jpegPhoto

The attribute Picture is in a Permission Set called Personal-Information. You can see the permission is applied to all users like this:

Control the Permission

They wanted to take away the permission for SELF to be able to write to the Picture attribute, but this shouldn’t be a high-level deny for Everyone to write to this attribute. It could be that some users somewhere at sometime need to write to this attribute.

What I suggested they do was de-couple the Picture attribute from the Property-Set called Personal-Information. Then apply an explicit permission to the root of the domain for a group which has write access to this attribute instead.

Unlink from a Property-Set

But how do you link (and therefore unlink) an attribute to a Property-Set?

The property sets are not found in the schema, but instead are found in the Configuration partition, under Extended-Rights.

Each of the Property Sets has an attribute identifying it, called rightsGuid. This GUID is used to pull in attributes as members of the property set by specifying the same GUID in the attribute of the attribute called attributeSecurityGUID. If these 2 GUIDs are the same, then the attribute will be a member of the Property Set. By removing the attributeSecurityGUID entry on the Picture attribute, it is no longer a member of the Personal-Information Property Set. And the SELF will lose permission to write to this attribute.

While this sounds very complicated, here’s a simple picture to explain it all:

The object on the left “CN=Personal-Information” is the property set. The object on the right “CN=Picture” is the attribute in the schema. It’s lDAPDisplayName is thumbnailPhoto. The attributes of these objects, rightsGuid and attributeSecurityGUID have the same value, a matching GUID.

Remove the GUID

When you remove the attributeSecurityGUID, open the attribute and click the button on the bottom left called “Clear”, as shown below:

Notice also that the text in the attribute editor isn’t the same as the text you see in the window behind. The characters appear as pairs and the pairs in the blocks have been switched around.

Undoing the Change

In order to restore the GUID if you change your mind, you need to copy the same form of the GUID from another attribute. I chose Post-Code as this is also in the Personal Information Permission Set.

I hope this helps someone else to delegate their Active Directory if needed.

Craig

Another interesting case with a nice, easy solution.

While working with a Premier customer recently we found that the 2 local groups relating to DHCP, “DHCP Administrators” and “DHCP Users” didn’t get created on their new DHCP servers.

Only the role installation steps can do this for us as that will make sure they were actually given the required rights to manipulate or view the service.

What to do?

We couldn’t just remove and reinstall the role – there was too much configuration already done.

We couldn’t ignore it as we were installing IPAM and it needs to place the IPAM servers computer account into the group “DHCP Users” on the servers. It does this by nesting itself into new a universal group in the domain: IPAMUG. This group is the one which actually becomes a member of the “DHCP Users” group.

The role was installed by a “next-next” manual installation using Server Manager. So it wasn’t as if some PowerShell or DISM.exe switch was accidentally left off. And if we repeated the manual installation, we would likely just end up where we started.

What went wrong?

At the end of the Server Manager wizard, you get this completion message (without the big red arrow, that’s my addition).

Inside there is a link to launch a wizard which will configure the DHCP server, called “Complete DHCP configuration”. This wizard does 2 things:

1. It creates the 2 groups we’re after: “DHCP Administrators” and “DHCP Users”
2. It authorizes the DHCP server in Active Directory if the DHCP server is joined to a domain

The authorization part is pretty nifty. Usually you do this by right-clicking on the server in the DHCP MMC console and selecting “Authorize”. This will create a object in the Configuration partition of the Active Forest under Services / NetServices for the DHCP server. Only members of Administrators in the forest root domain or members of Enterprise Admins can create objects here. The new wizard lets you type alternate credentials to do this job:

My customer had authorized their DHCP servers, by doing it the old way in the DHCP MMC console using an account with permission to do so.

They hadn’t noticed that small blue link from the image above. There is also a outstanding notification within any Server Manager console which connects to one of these DHCP servers (or on the local host itself). But that was also quiet subtle, and requires that you click on it to see the same blue link:

In fact, we hadn’t even noticed any of this by the time I’d found an alternative way of creating these groups on their DHCVP servers using netsh.exe:

netsh.exe dhcp add securitygroups

Had we run the wizard through to it’s completion, we would have got a success message like this stating that the local groups were successfully created:

I hope this helps someone avoid some troubleshooting time when deploying DHCP on Windows Server 2012.

Just a quick note to publicise that MBAM 2.0 is now out, and each of AGPM 4.0, DaRT8.0, App-v 5.0, UE-V 1.0 each received their own updates to Service Pack 1. They are bundled in the new MDOP 2013.

Read more about it here at the new home for the MDOP team: https://blogs.windows.com/windows/b/business/archive/2013/04/10/making-windows-8-even-more-manageable-with-mdop-2013.aspx

I recently became the proud owner of the fantastic Sonos PLAYBAR. And while the Sonos team is considering creating a Windows 8 App to control their devices, I found a neat little hack to get the DLNA portion of the Sonos to become a “Play To” device from within Windows 8 music apps.

See the blog post here:

https://digitalmediaphile.com/index.php/2013/03/30/using-uncertified-play-to-devices-on-surface-rt-w8-apps/

Here are the registry keys I created for the PLAYBAR: