Setting up IPsec with Kerberos on Server 2012 R2

Ok, so not strictly an SCCM related post but it might be helpful to many people struggling to setup IPsec.

We have recently been asked to ensure that all our SCCM 2012 servers communicate with each other using IPsec. Now, anyone who has tried to do this, having never done it before, will know there isn’t that much online on how to do this. At first hand it seems quite complex but actually its pretty easy to do.

I have only ever done this on Server 2012 R2, so I’ve no idea if this same process will work on earlier versions (give it a go and let me know!). Also, this is using Kerberos as the authentication method only (so obviously can only be done in a domain environment) and requesting IPsec, rather than forcing it (meaning non-IPsec computers can still communicate with the servers, albeit without encryption). Here is how we implemented it:

1. Login with an admin account, open up Services and ensure the IKE and AuthIP IPsec Keying Modules service is running and set to start automatically.
2. Open Windows Firewall with Advanced Security, right-click over Connection Security Rules node and select New Rule….
   
3. In the New Connection Security Rule Wizard, on the Rule Type page, select the Isolation radio button and click Next.
   
4. On the Requirements page, select the Request authentication for inbound and outbound connections radio button and click Next.
   
5. On the Authentication Method page, select the Computer (Kerberos V5) radio button and click Next.
   
6. On the Profile page, leave as default and click Next.
7. On the Name page, give the rule a sensible name and click Finish.
   

That’s it! Now obviously you’ll want to test its working and I’m sure you can use some sort of network monitor to do this but the easiest way is to use the tools in the firewall itself.

Simply set this up on 2 servers, have them ping each other (this is important as its starts the IPsec connection) and then go into Windows Firewall with Advanced Security again, expand the Monitoring node, then expand the Security Associations node and click on the Main Mode node (you may need to hit F5 to refresh the node). In the right window you should see any IPsec connections, along with the authentication method and encryption type:

IPsec away!

Inventorying App-V in SCCM 2012

I recently had to start inventorying virtual apps in SCCM 2012 and although its very easy to do, I noticed there isn’t much out there explaining the process.

How you do this will depend on whether you use App-V 4.6 or App-V 5.

Inventory App-V 4.6
WMI Class is located \root\Microsoft\appvirt\client

Once you have deployed an App-V 4.6 app to a machine the above WMI class should get populated. Then its just a simple case of going to Client Settings, Hardware Inventory, choose Set Classes and turn on the correct Classes for App-V 4.6, which are Virtual Application Packages (Package) and Virtual Applications (Application), selecting which ever values you need reporting back.

Inventory App-V 5.0
WMI Class is located \root\appv

Once you have deployed an App-V 5.0 app to a machine the above WMI class should get populated. Then its just a simple case of going to Client Settings, Hardware Inventory, choose Set Classes and turn on the correct Classes for App-V 5.0, which are AppV Client Application (AppvClientApplication) and AppV Client Package (AppvClientPackage), selecting which ever values you need reporting back.

Once the clients have updated their policy and ran a Hardware Inventory you can go to Resource Explorer > Hardware and you should see nodes for AppV Client Application, AppV Client Package, Virtual Application Packages and Virtual Applications, all showing virtual application data.

There are also a few default reports that are available to use:

SCCM 2012 Data Replication Service (DRS)

I’ve been troubleshooting a number of SQL replication issues recently and found a couple of great blogs to help. I’ll continuously update this post to list great articles that will help you understand and troubleshoot DRS problems.

Troubleshooting Initial DRS Synchronisation – http://blogs.technet.com/b/sudheesn/archive/2012/10/21/drs-initialization-in-configuration-manager-2012.aspx

Troubleshooting DRS – http://blogs.msdn.com/b/minfangl/archive/2012/05/16/tips-for-troubleshooting-sc-2012-configuration-manager-data-replication-service-drs.aspx

More DRS Troubleshooting – http://blogs.technet.com/b/umairkhan/archive/2014/03/25/configmgr-2012-drs-troubleshooting-faqs.aspx

 

2013 in review

The WordPress.com stats helper monkeys prepared a 2013 annual report for this blog.

Here’s an excerpt:

The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 26,000 times in 2013. If it were a concert at Sydney Opera House, it would take about 10 sold-out performances for that many people to see it.

Click here to see the complete report.

Hardware Inventory not being recieved by the Management Point

Me and a colleague have been working on an issue today where the Hinv from a client was being generated and sent but never seemed to be received by the MP.

When we checked the Last Hardware Scan value for the machine in Resource Explorer > Hardware > Workstation Status, we could see that SCCM stated the last scan was from over a month ago but looking at the InventoryAgent.log on the client, it clearly showed it successfully sent the report yesterday.

There were no errors (or even mentions) for this machine in either of the inventory components in Component Status in the console or in the MP_Hinv.log on the MP. Something was blocking the report between it being sent by the client and it being received on the MP.

Tho obvious answer for this was IIS, so we turned on IIS logging for the MP server and sent the Hinv again. Within a few seconds we saw:

170.60.210.69 BITS_POST /CCM_Incoming/{25F04BBF-0626-4989-921D-0B3EDA3B2A1C} (bits_error:{5FB9E647-D1DC-4211-8A68-2310B81E4E0C},403,0×80070005) 80 – 10.133.44.170 Microsoft+BITS/7.5 403 0 0 0

Obviously the bits_error part of this message immediately made us think there might be a problem with BITS on the client. As an initial troubleshooting step, we decided to try and clear the BITS queue of current jobs, using the below method:

1. Stop the BITS service on the client (use services.msc or “net stop BITS”)
2. For Windows 7 or Windows 8 go to C:\ProgramData\Microsoft\Network\Downloader. For Windows Vista and below go to C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader.
3. Delete qmgr0.dat and qmgr1.dat
4. Start the BITS service on the client (use services.msc or “net start BITS”)

Once the BITS queue had been cleared we ran another Hinv and the information was sent by the client and received by the MP successfully. The client also no longer created any errors in the IIS logs.

Problem solved.

Force an SCCM Client to use a particular AD Site

Did you know it was possible to make SCCM think that a computer is in a particular AD site, even though based on its IP address, it is in a completely different one?

You may want to use this for many scenarios such as a test environment, where you want to force a client to download from a particular DP.

It is very easy to do by simply going to the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

Create a new String Value called SiteName with a value of the AD Site you want to use.

Once it has been added, open up the SCCM Client on the machine and you will see that the AD Site Name has now been changed:

All software downloads initiated from this client will now take place from the DP that has the boundary for this AD site.

Collection query based on a machine being a member of another collection

Earlier today I was trying to create a collection that showed all machines that were in another collection.

This has to be done using a sub select query and the first one I used brought back all machines that were in a collection, based on that collection ID:

select SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.ResourceType, SMS_R_SYSTEM.Name, SMS_R_SYSTEM.SMSUniqueIdentifier, SMS_R_SYSTEM.ResourceDomainORWorkgroup, SMS_R_SYSTEM.Client from SMS_R_System where ResourceID in
(select ResourceID
from SMS_FullCollectionMembership
where CollectionID = “NOV00062”)

Unfortunately this only partly solved the clients problem, as he wanted to bring back all machines that were part of a collection where the collection name started with “Lab:”. This meant adding a join to the query, as the SMS_FullCollectionMembership table doesn’t include the collection name, only the collection ID:

select SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.ResourceType, SMS_R_SYSTEM.Name, SMS_R_SYSTEM.SMSUniqueIdentifier, SMS_R_SYSTEM.ResourceDomainORWorkgroup, SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.ResourceId in
(select ResourceID  
from SMS_FullCollectionMembership  
JOIN SMS_Collection on SMS_FullCollectionMembership.CollectionID = SMS_Collection.CollectionID
where SMS_Collection.name LIKE “Lab:%”)

Problem solved 🙂

Restart notification behaviour for software and patch deployments

Quite some time ago I had the need to document the restart notification behaviour of normal software deployments, software deployments within a task sequence and patch deployments. I wrote it all up in a draft blog post but never actually published it…..well here it is!

The reason I originally researched this is because we had a number of important users who got different restart notification messages depending on what they were installing and this became quite confusing! If they installed a patch they might get an 8 hour grace period before restarting but if they installed software (which unknown to them was done within a task sequence), they might get as little as 1 minute warning prior to a reboot.

It became important to document the behaviour, not just for our users, but our admins as well. Below are the results of the tests.

Normal Software Deployment and Patch Deployment

I’m sure most of you know that this is managed from the Computer Client Agent Properties under the Restart tab. The first option being the initial countdown, in minutes, once the patch or software has installed and a reboot is required and the second option being the number of minutes, prior to the forced reboot, a final notification will be shown to the user.

Software Deployment via Task Sequence

Things become a little more complex when you start using task sequences to deploy software and that’s because the above options no longer apply.

There are normally 2 reason why a reboot would take place during a running task sequence – when an application, that is being installed as part of an Install Software task sequence step, returns a 3010 exit code or when you specifically use a Restart Computer task sequence step.

If the reboot occurs due to the 3010 exit code, there will only be a 1 minute warning prior to the machine being force rebooted. I’ve not checked too intensely but I’m not sure if there is any way to change this setting, except to suppress the 3010 code in a script and do a controlled reboot using the Restart Computer task sequence step, mentioned below.

If the reboot occurs due to the use of the Restart Computer task sequence step, you are able to specify exactly how many seconds the notification message will be shown to the user before the machine is rebooted, in the step itself. The default is only 60 seconds and the max is 9999 seconds (about 2 and a half hours).

It is also possible to increase the value to above 9999 seconds, if required, by using a task sequence variable called SMSRebootTimeout. You simply need to add the Set Task Sequence Variable step to the start of your task sequence, use the SMSRebootTimeout variable and set a value in seconds. This then overwrites whatever number is used in the Restart Computer task.

Below shows me increasing the timeout to 8 hours:

If you want this restart value to apply to all task sequences that use the Restart Computer step, without manually changing each task sequence, you can also do this by adding the variable into the Collection Variables tab, under the Modify Collection Settings option on any collection. This will ensure that any machine in that collection, running a task sequence, will adhere to the value in the variable. If you need to overwrite the top level collection variable, you can also do this by adding the variable directly into the task sequence again and it should do so.

Hope that helps
Nik

Deploying modern apps to a 64 bit Windows 8 machine using SCCM 2007

Firstly, this is simply a post aimed at helping people deploy modern apps to Windows 8 machines. It doesn’t touch on actually creating the apps and getting them signed – that’s another matter and one which I don’t get involved in!

Secondly, before you do anything in SCCM, you need to ensure that you have turned on sideloading on the Windows 8 machine. Enabling this setting allows the installation of trusted app packages that do not originate from the Windows Store. To do so follow the below instructions:

So I was asked to help test deploying a custom modern app (via a Powershell script), to a 64 bit Windows 8 desktop, using SCCM 2007. All in all it was a fairly simple task but there were one or two issues we had to overcome, which might be of help to someone else out there.

I started the test by getting the source files (which included both a signed ps1 and appx file), creating a package and program in SCCM 2007 before deploying them to a test collection using an optional advert, much like any normal application. I did ensure that the program setting to “Allow users to interact with this program” was checked as I wanted to see any possible errors that would appear on screen.

When I first manually ran the advert I got the following error:

TestModernApp.ps1 cannot be loaded because running scripts is disabled on this system

This was a strange error as I was using a signed ps1 file and had already set the execution policy of Powershell on my test Windows 8 machine to AllSigned – http://technet.microsoft.com/en-us/library/ee176961.aspx – to ensure I don’t get any Powershell errors. After a bit of digging it turns out that on 64 bit machines there are two instances of Powershell, a 32 bit and a 64 bit version, both with separate execution policies. When I searched for Powershell in the Start screen and opened it as admin, it opened the 64 bit version only and so I had to run the same command on the 32 bit version as well. To do this I went to %windir%\SysWOW64\WindowsPowerShell\v1.0, opened up Powershell.exe as admin and ran the same set-ExecutionPolicy AllSigned command. I then ran the advert manually again and it no longer errored at this point.

If you are getting problems at this point, I suggest you set the execution policy of both instances of Powershell to Unrestricted but be aware of the possible security implications of allowing any ps1 script from running.

Unfortunately though, after fixing this issue another error then occurred:

add-appxpackage : Deployment failed with HRESULT: 0x80073CF9, Install failed.

Deployment Add operation rejected on package TestModernApp.appx install request because the Local System account is not allowed to perform this operation.

It is stating that, as I have set the SCCM program to “Run with administrative rights”, its using the SYSTEM account  to install the application, which is obviously causing a problem. With modern apps though, what needs to be remembered is that when they install, they do so on a per-User basis, unlike normal apps that install to the device. As this is the case it means that users don’t need to be local administrators to install modern apps. Therefore you need to set the program to “Run with user’s rights”:

After changing the program to the above, the modern app installed with no issues.

Staging Problems: BitLocker and multiple boot images

Over the last few days I’ve been working on setting up staging via PXE booting at a clients site. Everything seemed to be working fine until I tried to stage a machine with BitLocker installed and the hard drive encrypted.

Just after I selected the task sequence and started the process, as it was downloading the custom boot image, the task sequence error (0x80070070) occured. As it errored, I hit F8 to bring up the command prompt and took a look at the SMSTS.log, which showed:

There is not enough disk space left on this machine for staging the content for content PKG000ID

and

Boot Image package not found. There is not enough space on the disk. (Error: 80070070; Source: Windows)

This seemed very strange as I knew that the machine has plenty of space available on the HDD. I ran diskpart from the command prompt and saw that the BitLocker partition, which is 100MB in size, was set to the C:\ drive and the main, large, encrypted partition was set to the D:\.

I then noticed it was creating the _SMSTaskSequence folder on the C:\ and it all made sense. Further up in the log, I found the following:

Volume C:\ has 75358208 bytes of free space 
Volume D:\ has unsupported file system 
Volume X:\ is not a fixed hard drive 
TSM root drive = C:\ 

The X:\ was the current boot image, loaded into RAM. As the D:\ was the encrypted partition, it was inaccessible and so SCCM was using the 100MB BitLocker partition as the root drive and was attempting to copy the boot image to the C:\. This partition wasn’t big enough to hold it and so the TS failed. Simple right?

But hang on, why was it downloading the boot image at all? I am already in a pre-execution environment, why didn’t it just use this boot image? Well, when you first PXE boot a machine it will download a boot image from the PXE DP.

The boot image it downloads initially will depend on which one is associated with the task sequence that has most recently been advertised to the machine that is being PXE booted. Once the environment is fully loaded, you then get the chance to choose one of the advertised task sequences and if that TS uses a different boot image to the one loaded in RAM, it will need to download the new one to HDD. If the main partition is encrypted, it is then forced use the BitLocker partition and if that is too small, it will fail with the above error!

What about fixes or workarounds? Well lets just recap the scenario before we look at what can be done.

Scenario:
A BitLocker encrypted machine, with a BitLocker partition that is smaller than the boot image size, downloads one of the available boot image media at PXE boot. When the choice of task sequences to run shows up, a TS that uses different boot image to the one already downloaded, is selected. As a new boot image is required, it begins to download it but to the small BitLocker partition (as the main drive is encrypted and not accessible) and fails due to lack of space.

Workaround:

1. Limit the number of boot images on the PXE DP to one, so the initial boot image download during PXE boot is the same as the one used in the TS about to run. This of course means only task sequences with the same boot image can be advertised to machines.
2. Suspend the encryption on the machine prior to PXE booting and then the number of boot images on the PXE DP doesn’t matter
3. Increase size of BitLocker partition so it can download the new boot media (I haven’t actually tested this workaround but am confident it would work)

Other than this, there is no other way I’m aware of getting round the issue except formatting the HDD prior to PXE booting!

Thanks
Nik