Windows 7 hanging on 'Checking for Updates'

Recently I've had to install a fresh copy of Windows 7 in order to build up a SOE for a client.  The first thing I realised is that there's an update for the Windows Update agent itself.  DON'T DO THIS UPDATE!  Whatever you do!  

This will update the Windows Update to version 7.6.7600.320.  There are many issues that  have been documented with this version.  The most important I would say is the fact that you suddenly can no longer search for Windows Updates.  If you check for new updates, it will sit there saying "Checking for Updates" indefinitely.  

When imaging a new machine, ensure that you don't have it connected to the network, and when it asks to install updates, click "Ask me later".  Once you've done that, you will need to install two Windows Updates.  These you will need to download from another computer and it would be the best idea to copy it over through USB drive.

They are the following updates:

1. KB3020369

2. KB3172605

Make sure you install these updates in that order as well.  Once you've installed these updates, reboot your computer and then you will be able to go through and start downloading Windows Updates like normal. 

Cumulative Update for Windows 10 Download Hanging | KB3189866

Microsoft has recently released the Cumulative Update for Windows 10 Version 1607 (x64) which a lot of people have been having issues with.  The update is hanging when your workstation tries to download it.

Microsoft are currently looking into getting this resolved, but in the meantime, you can manually download this update from the following location:

http://go.microsoft.com/fwlink/?LinkID=116494&updateid=0405fe13-e4d5-4aff-8cf1-0500f5f673f7

Manually install the update, reboot and you're good to go!

You may need to restart the Windows Update service once you've rebooted if it thinks that it's still downloading the update.

External address pointing to internal server on a different port | URL Rewrite | Server Farm

This post continues from my previous post which outlines the same requirement, but without the use of Server Farms in IIS.  In this post, I will cover the rules required to achieve this whilst using server farms.  It is a different process because the use of Server Farms automatically creates ARR and URL Rewrite rules, so we have to work in with that.

Required Outcome
I have a website gis.domain.com.  This is this forwarded to the gis.domain.com server farm which contains this website.  It is a secondary IIS server.  TCP80 has the primary website.  There is a secondary website called webapp which is accessible on TCP8080.

My client would like to access gis.domain.com/webapp and have it re-write to <servername>.domain.local:8080.

To achieve this, all the work is to be done on the primary IIS website which maintains the Server Farms.

Rule #1
This rule is automatically generated when you set up Server Farms.  It will be called ARR_gis.domain.com_loadbalance

We need to amend this rule to show the following:

I have highlighted the sections that you will need to change from the default rule.  The rest of that rule can be left as-is.

Rule #2
The second rule will need to be created from scratch.  Create a new Blank Inbound Rule:

Add the following settings to that rule.:

Note: the Rewrite address is an internally accessible address only.  This is fine as the server is acting as a reverse proxy and will route the traffic internally on the new port.

Ensure that the Stop processing setting is marked as False for both of the rules.

And that's it folks.  That's all you need to get the rules working and to allow forwarding to different websites on different ports when you have a Server Farm. 

External address pointing to internal server on a different port | URL Rewrite | No Server Farm

This post is related to URL Rewrite on an IIS server which does not have server farms enabled.  I will create another post to cover the same process with Server Farms enabled as it's a completely different requirement.  Click here to find out more about Server Farms.

Recently a client has asked us to look into URL Rewrite and Application Request Routing to see if we're able to achieve the following:

• Access externally facing web address: subdomain.domain.com/webapp on port 80
• ARR and URL Rewrite then forwards this to <servername>.domain.local on port 8080

The easiest way to show you how this was achieved would be by just showing you the web.config file.  This is the file that's located under the Default Web Site which defines all the settings with IIS that we will be changing.  You will simply have to change all the items I've labelled in bold and underlined, to suit your setup, and then you should be good to go.

I will also explain each bold/underlined item under this web.config file so you know what you're changing. 

<?xml version="1.0" encoding="UTF-8"?>

<configuration>

    <system.webServer>

        <rewrite>

    <rules>

        <rule name="Reverse Proxy to webapp" stopProcessing="true">

            <match url="webapp" />

            <action type="Rewrite" url="http://ca.atlab.local:8080" />

        </rule>

    </rules>

            <outboundRules>

                <rule name="Outbound Rule - URL Rewrite" preCondition="IsHTML">

                    <match filterByTags="A" pattern="^/(.*)" />

                    <conditions>

                        <add input="{URL}" pattern="webapp" />

                    </conditions>

                    <action type="Rewrite" value="/{C:0}/{R:0}" />

                </rule>

                <preConditions>

                    <preCondition name="IsHTML">

                        <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />

                    </preCondition>

                </preConditions>

            </outboundRules>

        </rewrite>

    </system.webServer>

</configuration>

• WEBAPP
• Match URL="webapp"
• This is the section where it looks for the trigger to run this rule.  If you don't have "/webapp", then it won't rewrite your URL and redirect you to the new location
• http://ca.atlab.local:8080
• action type="Rewrite" url="http://ca.atlab.local:8080"
• Once you have triggered the rewrite by adding "/webapp" to your URL address, this is the location that it will forward the traffic to essentially.  In this case it's an internal server, but it can be any location (external or internal) on any port.
• WEBAPP
• <add input="{URL}" pattern="webapp" />
• This is the ARR section of the config.  This should be named the same as the first section.

If you're using Server Farms within IIS, here's how to achieve the same thing.

Configuration file is not well-formed XML | IIS

This one is a nice, easy one which I thought I'd post.

If you are changing rules or any config in IIS and you're doing it through applicationhost.config, there's a chance that you're going to corrupt the file and get the following error message:

Have no fear!  You can restore this file from a backup which is located in the following location:

C:\inetpub\history

Simply check the date that it was backed up and you can restore it from there.

Just copy and paste the applicationHost.config file and restart IIS and away you go!

Intel AMT: Configuration | AMT Status: Detected | Not Externally Provisioned

Recently I have been trying to setup and configure Intel SCS to leverage Intel AMT features through SCCM 2012 R2.  I've done this before and it's worked fine, but for whatever reason, with this particular client, SCCM is failing to detected that the workstations have been configured, and that AMT is Externally Provisioned (thus not allowing me to control the power etc).

After running the Intel AMT: Configuration Task Sequence (which works by the way), I get the following messages in the AMTOPMGR.log file:

I've tested that I can log into the web GUI with the admin credentials and that's all fine, but for whatever reason, I'm getting AMT Status is 1 which translates to 'detected', rather than 'externally provisioned'.  I checked all my settings and everything had been configured accurately.

The machine account was in the appropriate ACL which was mentioned in the SCS profile (that's a big one if you haven't done that).  There was nothing online which actually related to the issue I was having, so I logged a ticket with Intel themselves.  After a couple of hours of troubleshooting with an Intel guy from Oregon, US (who was very helpful) we basically came to the conclusion that we couldn't find out what was actually causing this error message.  Everything had been configured correctly.

With the end goal in mind and wanting to be able to start up lots of computers, or a single device using the AMT Wake-Up feature, we comprimised and used a third party application called MeshCommander.  This application is installed on the SCCM server and essentially provides a whole lot more functionality to the Out of Band Management through SCCM.

To obtain the AMT Functionality, run the Intel AMT: Configuration Task Sequence as per ususal.  Then run the Discovery AMT Status like you normally would.  It will show up as Detected which is fine.  From here, you can right-click on a device and click on the MeshCommander option:

Select Kerberos and TLS.

Once you have done this, and provided there's nothing wrong with your AMT Configuration TS, it will allow you full access to the Intel AMT section of that workstation.  Allowing you to power the device up and use Serial over LAN etc.

If you're wanting to power up an entire device collection, simply right-click on that collection and select the MeshCommander Option:

Whilst I was pulling my hair out trying to get this one resolved, I'm actually grateful that I had this issue, because the solution that Intel suggested to achieve the overall outcome seems to be a lot better than the initial solution of simply using the Power-On feature through Intel SCS and SCCM.

Overall, this is actually a much better way to control the machines through Intel AMT.  I highly recommend it.

Intel SCS/SCCM | Intel AMT: Configuration Task Sequence | Failed to parse the XML file

I have recently been setting up Intel SCS/AMT configuration with SCCM 2012 for a client of mine. It's all going fairly smoothly but I noticed that when testing the Intel AMT: Configuration Task Sequence, it's failing (across multiple test machines).

Checking the SMSTS.log file, I can see the following error message:

"Failed to parse the XML file. Possible reasons - the file does not exist or access to it is denied; the file contains incorrect parameters; incorrect or missing encryption password/parameter"

At the end of this error message, it references the .XML file that I have setup as part of the configuration requirements.  

I checked the following

• Location
• Confirmed the .XML file is in the same location as the ACUConfig.exe file.  If it can read the one, it's reasonable to assume it can read the other.
• Ensured that this had been packaged correctly and the distribution points had been updated.
• Permissions
• Ensured that permissions on the files and the folders allow the service account to access these files.
• Password
• Confirmed the password was correctly added into the configuration.bat file.
• Decryption
• Confirmed that I could access this .XML file using the password that had been added to the configuration.bat file.

I then decided to go through the ACU Wizard again to create a completely brand new .XML file.  This was just to humour the issue to see whether it had something to do with the file itself.  Needless to say, we got the same issue.

The next thing I tried to do was run the SCSEncryption.exe file manually to see whether it could decrypt the .xml file. This was successful:

So this confirms that decrypting the file isn't the problem and that the password is in fact correct. Nevertheless, it's still failing with the same error message.  The last thing I tried was to copy the ACUConfig.exe, the associated DLL, the XML and the Configure.bat files to a local machine (Desktop) and then run the configure.bat file from there.  This means that it will be referencing the file that I 100% know is there.  When doing this, I still got the same error message:

To work around this and to get this up and running (which obviously was the priority here), I improvised and actually leveraged the decrypted version of the XML file.  I ran the SCSEncryption.exe file against the XML file which then replaces it with the decrypted version.  I edited the Configure.bat file to remove reference to decryption and the password.

.\acuconfig /output console /output file ConfigAMT.log /verbose ConfigAMT ".\XMLDocumentName.xml" 

Taking the decryption completely out of the equation, I updated the Task Sequence, and then ran it again.  This time it was successful!  

I'm sure re-installing the add-on and re-creating all the files would have also worked, but that wasn't an option in this case.  Whilst the XML file is no longer encrypted, you can use NTFS permissions to ensure that only the service accounts can access and view this file.  If you do this, it should be no different to if you left the XML file decrypted, except now it works! 

Asset Intelligence | SCCM | Expired credentials/certificate/token | Need to re-provision online account

This one is a nice and easy one.
If you're using SCCM 2012 and you're wanting to leverage the Asset Intelligence site role, you will most likely encounter the following error message if you haven't been assigned a certificate from Microsoft.

When you go through the initial setup, it will ask you to add the location of a .pfx file which would have been supplied by Microsoft.  In order to resolve this and allow SCCM to connect to the Microsoft Database, you will need to obtain a certificate.  This can be downloaded from a Microsoft Hotfix (https://support.microsoft.com/en-us/kb/3060648).  You can also obtain a certificate from your Microsoft account rep.  

You will need to extract these files and then you will find the certificate file.

Once you have this certificate, you will simply need to add it into the properties for the Site Service Role:

After you have updated this setting so it's using the certificate, you will then need to disable and then re-enable the Asset Intelligence Sync point.  Simply un-tick this, apply, then re-tick and apply again.

Intel SCS: Platform Discovery | Task Sequence Failing

So I am currently in the middle of setting up and configuring Intel SCS to leverage Out of Band Management through SCCM 2012 for a client of mine.  This is something I have done before and didn't have a problem with, but in this environment, for some reason I'm having a few issues.

After installing the SCCM add-on, I enabled the Intel SCS: Platform Discovery add-in, which was created automatically.  I deployed it to a number of computers to ensure that it's working and that the machines show up in Intel AMT: Exists Device Collection.

Unfortunately I ran into some issues with this one:

The above are the error messages that are showing up within the SMSTS.log file.

From here, I changed the package to download all the data locally, then to run the TS.  When this happened, I got a different error saying that it couldn't locate the ACUConfig.exe file.  I copied this file over to the Platform Discovery folder, along with the associated DLL.

Once I had done this, the package was then updated to the distribution points and the Task Sequence was then re-deployed.  I selected the TS to download all the data locally before running.  This now seems to be working fine!  

I've refreshed the Device Collections and they're populating as intended.  The weird part is that I've had setups which have worked perfectly fine without having to manually copy these two files over, but for some reason, this time it just wasn't working. 

The good news is that this is now working for us!