Some Notes on the Machines

Not sure quite what this is yet, but the description is intriguing:

https://downloadcenter.intel.com/download/24075/Intel-Extreme-Tuning-Utility-Intel-XTU-

Integration services are no longer automatically installed or automatically available, to guests running operating systems older than 10, on hosts running 2016. They have to be installed by powershell or DISM, directly into the guest, not the host. I found DISM to work when powershell didn’t. The appropriate image addition is downloaded here:

https://support.microsoft.com/en-us/help/3071740/hyper-v-integration-components-update-for-windows-virtual-machines-tha

and then installed thus, e.g. for Windows 7/2008R2:

DISM /Online /Add-Package /PackagePath:C:\storage\windows6.x-hypervintegrationservices-x64.cab

A good tool here:

woshub.com/how-to-measure-disk-iops-using-powershell/

Once having downloaded and unpacked this or this, get to an administrative PowerShell, and here’s the command:

.\DiskPerformance.ps1 -TestFileName test.dat –TestFileSizeInGB 1 -TestFilepath C:\temp -TestMode Get-SmallIO -FastMode True -RemoveTestFile True -OutputFormat Out-GridView

It is important to use a -TestFileSizeInGB larger than the cache on the RAID, and set -TestFilePath to a folder on the RAID whose IOPS capacity you need to measure, or else you will not be measuring the correct data.

This is very helpful when we need to increase performance on a Hyper-V guest. After CPU and memory usage are good, with their averages being medium or low, the last bottleneck is hard drive bandwidth. If you get this right you can improve Hyper-V guest performance a lot:

1. Browse to the Advanced under each VHD, there is a QoS section.
2. The above performance test will run several times if you let it. Approximate the maximum by a rough average of the list.
3. For now, let’s say all VHDes are on the same RAID, and that you ran the above correctly on that RAID (-TestFilePath has to be set!), and that you averaged the values given to about 1800.
4. For each VHD, set the minimum QoS to 100 (5%), and the maximum to 1700 (95%). This makes sure that the hypervisor doesn’t let any of them “spin down” all the way, so latency is nice and low; and it also makes sure that the hypervisor knows to give the guests priority on their RAID volume.

This is something new to Windows 10/2016, a C runtime library different than the redistributables. It is a required additional install for some things to run on OS before 10/2016.

www.microsoft.com/en-us/download/details.aspx?id=50410

This is is caused by bad permissions in a receive connector. The fix:

1. Open ADSIEdit
2. Browse to Configuration, Services, Microsoft Exchange, , Administrative Groups, Exchange Administrative Group, Servers, , Protocols, SMTP Receive Connectors
3. Open the properties for the receive connector(s) involved in the transmissions you are debugging
4. Open the Security Tab. Under “Authenticated Users”, make sure “Accept any Sender” and “Accept Authoritative Domain Sender” are checked.
5. Wait five or ten seconds, and try again.
6. If still not, or if it works for a little while and then does the error again, you probably have severe issues in your Exchange. For a stopgap, you can set permissions for Everyone, but an Exchange rebuild is probably warranted.

Here’s a rundown:

https://blogs.msdn.microsoft.com/johan/2008/10/01/powershell-editing-permissions-on-a-file-or-folder/

From the extraordinary Mike Hunsinger.

The method below has worked perfectly on several servers and has not caused a recovery situation. That said, assure there’s good backups and perform these procedures word-for-word as these Exchange updates have been known to bootloop and bluescreen servers, particularly SBS servers when the original (and these days, ancient) install was not very cleanly done.

The key is to determine the current Exchange SP level, then based on the current version, plan your updates like this: First, install the highest-level rollup for the current SP. Then install the next SP by version. Followed by that SP’s highest-level rollup, then the next SP.

Here’s an example:

Your 2010 Exchange Server is using SP1 RU 3 (Roll-Up3). You intend to upgrade this system to SP3 RU14 (Latest version of Exchange).

Here’s the order in which you should install the updates based on this exchanges current version:

1. Update Rollup 8 for Exchange Server 2010 SP1 (Highest version of SP1)
2. Exchange Server 2010 SP2
3. Update Rollup 8 for Exchange Server 2010 SP2 (Highest version of SP2)
4. Exchange Server 2010 SP3
5. Update Rollup 14 for Exchange Server 2010 SP3 (Highest version of SP3)

Notes found to be important:

• Assure the server’s OS itself is running the latest service pack for Windows Server.

• Exchange SP’s must be downloaded from the web and installed using an exe. Roll-Ups must only be installed via Windows Update.

• Using this pattern of installs and installing Roll-Ups using only Windows Update, will prevent having to perform the lengthy staging process where the mailbox databases are manually converted between versions using CMD.

• Completely review the prerequisites for each Rollup and SP before installing it. There are corroborative softwares such as .net and sql client or certain hotfixes that may need to be installed prior to a given service pack or roll-up.

• During the Service Pack updates, you will see a long checklist the server is moving down while performing the upgrades. If the server errors on one of the checklist items and asks if you wish to continue or roll-back. ROLL IT BACK. Resolve the issue noted and try the update again. You want all 10 lights green when it hits the bottom of the checklist. Errors here are usually the result of insufficient permissions someplace in the server. The errors are usually easy to trace down online.

• Between every update listed. Launch the ECM. Assure the mailboxes are all listed. Then run the builtin Exchange testing. If Exchange says it’s passed, move onto the next update. If Exchange fails any factors, they must be eliminated before continuing.

• Allow up to 1 hour for the server to reboot following an Exchange SP Upgrade. It’s advisable that ILO be activated prior to installing the upgrades described in this document, so you can keep an eye on the server while it reboots.

• I usually allow 1.5h for each service pack and it’s associated rollup.

• It never goes exactly smoothly, so there’s usually some challenges to overcome during each of the updates.

First in a series on improving Windows Group Policy. This apply to the whole Group Policy milieu on a network, all domain controllers.

• Even if there is only one domain controller, change the replication from 180 minutes to 15 minutes. These are in the properties of the site links, in Active Directory Sites and Services, under Inter-Site Transport, under IP. If you have more than one site link enabled, do it for all. Obviously you should moderate carefully, if you are using SMTP or have bandwidth issues.

• Set services fdPHost and FDResPub as startup Automatic, from Manual.

• Add Subnet(s) to each Site in Active Directory Sites and Services. Then show subnets in the Group Policy Management Console, and map group policies there. Even if there is only one Site, this can help a lot.

Part II, Destrangulation, is here.

Third in a series on improving Windows Group Policy.

Group Policy can and sometimes needs to copy files. If it fails, when you run this command:

GPRESULT /H gpresult.html /F

and look at gpresult.html in a web browser, you may see a permissions error, 0×80070005. This is commonly because your source file is not readable. To make this right, working advice appears to be to give read-only access to the source location, to “Authenticated Users”. Obviously this is not secure enough for some applications of this, but at the moment it is not clear what will work. “NETWORK” does not work, “SYSTEM” does not work.

But this page is a work in progress, the above permissions are clearly not satisfactory for many circumstances.

Reportedly, for user-level group policy items, the group policy engine runs with the permissions of the particular user logging in. But this does not make sense with the above, because any user logging in will be a member of “Authenticated Users”. So the engine must run as some other authenticated user, given that the user is apparently not counted as “logged in” while the engine is doing the above.

For computer-level items, the group policy engine runs with the permissions of the computer itself. This means that file copying may be quite a lot more reliable if it can be done without user information, e.g., to the public desktop et cetera. This should work by adding the security group “Domain Computers” as read-only to the source share.

Second in a series on improving Windows Group Policy.

One very common Group Policy strangulator shows up in Windows event logs as SceCli, event ID 1202. When Group Policy processing encounters this, it can prevent many things from occurring.

The error, specifically, is a nonexistent user or group present in a GP configuration item. For instance, most recently there was a Group Policy including a security item which included “Domain Uers”, a typo of “Domain Users”, deep in computer-level security items, and this prevented the policy from doing anything, even though there were other, equivalent, items in the same area. I’ll repeat, the typo item had to be removed, before the entire policy would do anything; group policy processing is apparently not able to treat a nonexistent referent as irrelevant.

Finding the item is interesting too. It requires a file of this name and location:

%SYSTEMROOT%\Security\Logs\winlogon.log

It may not exist. If not, or if it’s not up to date, browse to this registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}

and set DWORD ExtensionDebugLevel to 2. Then run gpupdate, and the file will be created. Then in administrative CMD, run:

FIND /I "Cannot find"  %SYSTEMROOT%\Security\Logs\winlogon.log

The above will produce one or more invalid security group names or login names, included somewhere as a configuration item within a group policy. Once you have the name(s), run:

rsop.msc

and examine all of its tree carefully, to find the error. That will lead you to the spot in GPMC where you will find the bad entry, to fix. Once you have fixed, try your gpupdate again, and your policy will apply, unless something else is wrong!

Part III, Copying Files, is here.