Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the urvanov-syntax-highlighter domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in C:\home\site\wwwroot\wp-includes\functions.php on line 6114
May 2015 – A Geeks World

Disable inactive computer accounts script

I did a webcast today about automating management of the datacenter with group policies and scripts. It was in Swedish, but I’ll make a blog series in English and share that information with all of you.

One of the attendees asked for the quick-and-dirty script I’ve scheduled to disable inactive computer-accounts. Here it is.

I’ve scheduled it to run with a Scheduled Task deployed in a GPO that only applies to the PDC Emulator, so all DC’s doesn’t run the script.

 

The Interactive Services Detection service terminated with the following error: Incorrect function.

This morning I noticed that one of the Hyper-V Hosts at a customer were logging this error regularly in the system Eventlog;

The full detailed entry:

It looks like the events are happening every  30 minutes, and at the same time as Windows is for some (so far) unknown reason doing a reinstall of a lot of MSI packages, and the above Interactive Service is triggered at the same time as it’s reinstalling the DHCPExt.msi

I can so far unfortunately not find anything that’s logging why Windows is reconfiguring all MSI Packages on the server every 30 minutes.

It does look like it’s the DHCP Server extension that’s causing the Interactive Service errors, as they always happen at the same time. Though, the DHCP Server extension shouldn’t be reconfiguring in the first place.

We always enable the Reliability History on all servers whireliabilitych can be handy at times to see when a problem begun happening.
Check this Out!

It looks like the problem started on April 28 at 8:42 PM.

As the Reliability History tool is disabled by default, I’ll make another blogpost showing how you can enable this feature for all your servers.

Weventloghen I wanted to see what had happened around April 28th. I noticed that was the oldest entries in the Application log. When the log has become full, it has removed the oldest entries according to the settings.

So I don’t think I’ll get any more details that way, and it does look like this problem has gone on for quite some time.

I’ll just reinstall the Hyper-V Host as it’s done in a few minutes compared to spending hours trying to fix the problem.
AND… I’ll create a Group Policy that will increase the Eventlog Size to x10 the default. So the next time something like this happens, I’ll have information to dig deeper.

Updated 2015-05-19 09:08:

After doing some more digging, it seems according to this KB Article (KB974524 : Event log message indicates that the Windows Installer reconfigured all installed applications) that this problem can happen if one of the following is true:

  • You have a group policy with a WMIFilter that queries Win32_Product class.
  • You have an application installed on the machine that queries Win32_Product class.

As the problem is not happening every 90-120 minute which would be true if it was GPO Triggered, I would say it’s an application that uses the Win32_Product class. And after doing some digging, it turns out it’s a known problem with VMM which will be fixed in UR7. Or hopefully earlier with a hotfix.

Updated 2015-05-19 10:12:

Wow, I got a hotfix for the issue within 15 minutes after contacting the VMM Team.
I’ve just installed it in our test environment and will later install it in the customers production environment.

Unfortunately I don’t have a KB or Hotfix ID for this, but if you contact Premier Support I think you can mention that you need a hotfix for Engine.Adhc.Operations.dll which gives support for RegKey: UpdateDHCPExtension
That info should make them able to find the correct hotfix.

Update VMM Agent via PowerShell

PowerShell script to update VMM Agent on all VMM Managed Computers after Update Rollup is installed on VMM Server.

You can find the AgentVersion here: http://social.technet.microsoft.com/wiki/contents/articles/15361.list-of-build-numbers-for-system-center-virtual-machine-manager-vmm.aspx

 

Unable to Connect to VMM in AzurePack after UR install

After upgrading to Update Release 6 (UR6) we got the same issue as seen in earlier UR’s. It’s not possible to connect to VMM in AzurePack so you can’t see your Virtual Machines, Clouds or Networks.

It turned out that when UR6 gets applied to SPF, the bindings are once again messed up. To fix this, just logon to the server hosting SPF and in IIS check the bindings as seen here;

SPF1

The SPF Website is not running and you can see two Bindings.
In my case, one has a certificate and the other doesn’t. So I just remove the binding without a certificate. Then start the Website and everything is working as expected again.

In earlier UR’s I’ve also seen how there is no bindings at all listed here. So you may have to create some binding then.

 

The request size exceeded the configured MaxEnvelopeSize quota

Today when I was updating our AzurePack WebSites Servers, I got an error which prevented the upgrade of most of the WebSite Roles like these;
Management Servers, Publishing Servers, Front End Servers and all the Web Workers. Yes, everyone except the Web Sites Controller.
Resulting in some unexpected downtime.  Luckily, all that was affected was this blogsite.

The error message I got was;
The WinRM client sent a request to the remote WS-Management service and was notified that the request size exceeded the configured MaxEnvelopeSize quota.
And I could also see that the files being copied to c:\windows\temp (WebFarmAgent.msi) were broken.

I also had an error “Failed to copy role artifacts to agent” in the logfile seen on Windows Azure Pack Websites Controller.

First of all, I ran this command in an Elevated Command prompt on the server hosting the Controller Role;
C:\Windows\system32>winrm g winrm/config

winrm1

And then the same command on one of the failing servers;
C:\Windows\system32>winrm g winrm/config

winrm2

Notice the difference in MaxEnvelopeSizekb between the servers. One of the other servers had MaxEnvelopeSizeKB set to 700.

I don’t know why it’s different between the servers or what has suddenly changed it, my guess it’s some Windows Update patch. Though it’s the same patches being installed on all the servers, and I’ve seen three different values. Wicked.
So by using the same value on all the servers I got the setup to work. And as you can see, this blog site is now also running. YAY!

I chose to set the value to the same as on the Controller Server which is the one trying to run the commands and copy the files to the other servers.
winrm set winrm/config @{MaxEnvelopeSizekb=”8192″}
It will now take 5-60 minutes for all update and repair jobs to complete.

I couldn’t find any Group Policy object to use to set that value as a default value on all AzurePack WebSites servers. So I’ve got to come up with another longterm solution. Maybe doing it with Desire State Configuration (DSC) or via Configuration Manager?

Storage Spaces Deep Dive on Microsoft Virtual Academy

I’ve together with my colleague Mikael Nyström (www.deploymentbunny.com) and Ola Skoog (@ITPrOla) from Microsoft, recorded 4 sessions about Microsoft Storage Spaces at Microsoft Virtual Academy called “Storage Spaces Deep Dive“.
The sessions are focusing on Design, Best Practices, Performance and Troubleshooting.

Feel free to contact me (markus.lassfolk at truesec.se) if you have any questions about Storage Spaces.