I had a scenario on client site to ensure the ‘Disable Bitlocker’ Action did not run for Virtual Machines. I did not have the MDT Toolkit running ‘In OS’ therefore I could not pull in the ‘IsVM’ variable therefore I wanted to exclude based on retrievable attributes from WMI.
Instead of the normal ‘like’ statements I used the below which you could adapt:
SELECT * FROM Win32_ComputerSystem WHERE NOT Model LIKE “%VMware Virtual Platform%”
SELECT * FROM Win32_ComputerSystem WHERE NOT Model LIKE “%Virtual Machine%”
For me this covered both VMware and Hyper-V virtual machines.
Recently I was working for a client on a Surface Pro 3 project with a very clean foundation platform as I like to do for a dynamic build. One disadvantage (which would fill a blog of opinions on its own) is the Office Install which can often take a long time.
I had a scenario whereby during this step my Surface Pro’s would drift off to sleep and until they were woken would simply ‘sit’ during the build process until an action on the keyboard or mouse was performed. They would then carry on.
After a bit of digging, during the OSD process the Balanced Power Scheme is applied as default from Windows 8.1 which includes the 10 minute sleep function. As Office takes longer than this it impacted the devices whether plugged in or not.
To combat this issue I placed a conditioned step in the Task Sequence to remedy the situation:
This will allow the build process to continue uninterrupted and allow the normal GPP Power Settings to apply once you get into Windows for whatever your power policies are.
One new feature brought about from ConfigMgr 2012 SP1 onwards is a Task Sequence variable known as SMSTSPostAction.
This variable is used to store 1 (Yes Just 1) post action task which connects the Task Sequence to the Windows Environment.
The Variable is to be set during the Task Sequence (perhaps near the end).
The scenario I have found it most useful is a simple restart command which will initiate Group Policies to apply (particularly useful for GPP’s) as this acts differently to the ‘Restart’ action initiated by ConfigMgr.
Example of use:
The example I have used it for is simply to restart the machine to allow my Group Policies and GPP’s to apply after the Windows 8.1 Task Sequence has finished to save the support team initiating a restart.
Hope this help and I am sure it can provide a multitude of uses.
A look through a number of my blogs would give the impression I am none to fond of the ConfigMgr 2012 Application model 🙂
Whilst I accept its positives the negatives are also there for all to see.
Now to the point in hand.
If you are attempting to install an Application which by all accounts appears to be installing but the below error in Software Center displays:
This error essentially is ConfigMgr 2012’s way of telling you that although the application installed successfully, it is however unable to validate the detection method successfully resulting in the failure. More evidence is shown in Appenforce.log
To remediate the issue you will need to find a detection method that is acceptable. This mainly affects NON-MSI based products and in my example RSAT for 8.1 and Server 2012 is installed via an MSU so I need to find a better way than my first attempt ( A Registry Key 🙂 )to get this operational.
For this Example I used the Software Distribution path in C:\Windows as my validation but if you imprint your machine after an install this would also be a viable option to pick up the install.
There are many many ways to achieve the above but the scenario where I find this fits in most is with ConfigMgr 2012’s new Application model which while it has its pro’s it certainly has a long way to go in order to completely replace the packages.
The main issue I have seen on client sites has been around their use in a Task Sequence after a reboot. After the restart the machine comes online again and the agent re-establishes a connection. Particularly on machines with an SSD drive, everything happens very quickly and sometimes the build end up failing with a (405) error which is simply the Task Sequence trying to run before it can walk so to speak.
To allow it time to get up to speed a pause works great. The disadvantage of using a script is its yet another package which if it has an issue with not communicating another package will likely hit the same issue.
This is a simple command line step utilizing PING which is right out of the box 🙂
Simply create and amend as you wish but 1 minute is usually more than enough
Since the release of ConfigMgr 2012 global conditions have helped support the Application model in a way that we can present the same application to users however based on criteria limit which deployment type is applied.
This does work well however like everything in its first revision this can be limited at times given limited support about what they are actually for.
Below illustrates a way I have used the global condition to tidy up a very complex deployment that involves deployment out to a machine however can equally be used for users if adapted.
The Scenario:
I am working at a legal client who have a piece of software that uses the same base MSI however a number of MST’s produce the end result (4 in fact). Now I could create 4 different applications for each one which would be linked to a collection via a deployment and work perfectly fine. In this scenario there are a number of components that make up this application (Drivers, Optional Components etc) so I am looking for a way to trim down the amount of Applications/Deployments and keep it tidy whilst utilizing a sohpisticated method.
Problem:
I have 1 MSI with 4 MST’s however the nature of how Applications work is that when AppDiscovery.Log runs, the first Deployment Type which criteria is satisfied this deployment type will run. So how do I have all four together in 1 application in the same way that we could have multiple programs in the same Legacy Packages.
Potential Solution: Global Condition
The golbal conditions are there to determine ‘if’ a deployment type should run as shown below and example for Primary device:
So if we have our flavours of deployment delivered via AD groups, a Global Condition could be used to say ‘if’ machine/user is a member of an AD group it satisfies the requirements!
Great Right?????
The Problem:
At present the official stance coming out of Microsoft are that Global Conditions are not designed for use in this way and that they are a real-time check on if a deployment should take place. Personally I do not see why this should be any different for this but please proceed and do your own due diligience on this first.
The Solution:
This is formed of 2 parts. First we need to create a Global Condition which effectivly runs a script to pull out what we need. In this case, I want a string of all groups a PC is a member of:
Create a Global Condition named accordingly and you want to set this as a Script/Sting and it to be a VB SCript (You could re-write this in Powershell of course!)
Now the script needs to be entered. This can be done if you have a store for Global Condition scripts you use, or simply write directly into the screen:
The Full Script is listed below. You will need to add in your Domain Short Prefix where highlighted:
*********CODE START*****************
‘On Error Resume Next
‘ List Other Groups a Group Belongs To
Set network = WScript.CreateObject( “WScript.Network” )
computername = network.ComputerName
getDNvar = GetDN(computername)
Set objGroup = GetObject(“LDAP://” & getDNvar)
objGroup.GetInfo
arrMembersOf = objGroup.GetEx(“memberOf”)
‘WScript.Echo “MembersOf:”
grplist= “MembersOf:” & vbcr
For Each strMemberOf in arrMembersOf
objGroup=””
‘ WScript.Echo strMemberOf
Set objGroup=GetObject(“LDAP://” & strMemberOf)
grplist = grplist & objGroup.SAMAccountName & vbcr
‘ WScript.Echo objGroup.SAMAccountName
‘ If Err.Number <> 0 Then
‘ Wscript.Echo “No Groups Defined”
‘ End If
‘On Error GoTo 0
Next
Wscript.Echo grplist
Function GetDN(strName)
‘ Constants for the NameTranslate object
Const ADS_NAME_INITTYPE_GC = 3
Const ADS_NAME_TYPE_NT4 = 3
Const ADS_NAME_TYPE_1779 = 1
‘ Use the NameTranslate object to convert the NT user name to the
‘ Distinguished Name required for the LDAP provider
Set objTrans = CreateObject(“NameTranslate”)
‘ Initialize NameTranslate by locating the Global Catalog
objTrans.Init ADS_NAME_INITTYPE_GC, “”
‘ Use the Set method to specify the NT format of the object name
objTrans.Set ADS_NAME_TYPE_NT4, “INPUTHERE\” & strName & “$”
‘ Use the Get method to retrieve the RPC 1779 Distinguished Name
GetDN = objTrans.Get(ADS_NAME_TYPE_1779)
End Function
********* CODE END*****************
Once this has been created (test your script first on your PC 🙂 ) you can now reference this in deployment types as an example below:
Important Note is you MUST use Contains!! This is due to searching the string if the object is part of more than one group. Mine is simply the name of the AD Group the machine is part of.
As I have said above, the ‘official’ statement is that the Global Conditions are not for this purpose but I feel this add a very good ‘chink’ in the Application Armoury as the migration of away from packages occurs.
This is a second post in a matter of days and although I like the new App model I must admit I am far from impressed on its current stabilitly and apparent frailty when compared to regular packages.
Aside from the dependancy in and around Build & Captures, at present the revision history seems to play potential havoc inside of Task Sequences in certain instances as outlined below:
When building a machine from a Task Sequence, an application (or multiple) will fail and produce what is apparently an access denied message (0x80004005) however the NA Account is configured correctly and all boundaries are in place.
The source of the issue can be traced to the revision history in the Task Sequence being referenced to an incorrect version causing the install to fail.
This explanation is detailed in this excellent post
Although I like the new App model I feel it has some way to go before moving away from Packages all together.
Since the release of ConfigMgr 2012 Microsoft has employed a more dynamic approach towards application delivery in the form of Applications as opposed to standard Packages. These work in a similar way but come into their own for more complex applications requiring dependancy and being able to determine the presence on a machine rather than using scripts etc.
Although I use these for alot of customers I must admit there are instances where I still prefer the older model as there are advanced elements of troubleshooting where they are easy to get to an issue but also the stability of the platform still does not seem to have been ironed out.I have had countless instances where packages of the same source work fine but produce unrelaible results when working inside of OSD.
Nice lead onto topic 🙂
For one client I decided to move the Build & Capture over to pure applications where possible as opposed to packages and stumbled over an instability when producing the build and capture where they would not install.
Now I try to follow my own rule of thumb/best practice for Gold Deployment which is as follows
VM (Hyper-V)
Non-domain joined during sequence
This scenarion for a package version of the TS works a treat with no issues however transitioned to applicaiton it failed as soon as it hit the first package.
so what options are availible????
The cleanest option I have used to remediate requires a couple of adjustments:
1 – On the Setup Windows and ConfigMgr step, add in the SMSMP=YouCMbox.FQDN
2 – While I was performing the Build and Capture I added in an IP Address Boundary into the boundary group where the contents was located.
This resolved the issue and allowed the Applications to install.
So why is this required?
Well…… Assuming you dont join the domain during the Build & Capture and then Dis-Join (which is an option, just place in an OU with no policies!), the client is unable to query AD for the vital MP information so it needs to be spoon-fed with all the information it would otherwise gather on its own and without that information it is unable to access the Applications.
This issue is not a problem for standard packages which is just a number of differences between the two.
Ill admit im yet to be completely sold on Applications but will endeavour to try to adopt the new practices wherever possible 🙂
Although it has only just hit technical preview, I have decided to switch my Win 8.1 Hyper-V host over to Windows 10 while testing out new OSD Deployments via ConfigMgr 2012 to see how it fairs.
On the whole it stands up pretty well but one thing I did notice was on my Task Sequence the network adapter I had for the Win 8 Hyper-V host did not work on the Win 10 host and therefore the build failed.
I was unable to locate a .ISO on the tech preview to extract the driver which installed as part of the OS so I used the following useful tool:
http://www.boozet.org/dd.htm
The Driver download tool (once installed on a Windows 10 VM inside Hyper-V) allowed me to extract the Hyper-V driver I required and from there I could import this into ConfigMgr and add to my Hyper-V driver package. As you will see below the version of the NIC driver is 6.4 which is (at present) the build type for Windows 10
I would not recommend this for Production Build & Captures incase it layers any untoward issues from a network driver perspective but as a funtioncal build test platform it has held up well so far!
Since the release of System Center 2012 R2 there have been (to date) 3 Cumulative Updates which if you wish to keep your clients upto date will need deploying into your ConfigMgr hierarchy.
During the OSD Process the most common place you will see this is below:
This can sometimes be problematic and prone to issues however there is another way…………
Note * The below has not had an official stamp off from Microsoft so please test and use at your own risk however this has worked since 2007 and I have not experienced any known issues.
After completing the installation of the CU on your site Server you will have the hotfix files placed in the following area:
\\[Site Server\SMS_[Site Code]\hotfix\[Hotfix KB]
Within the directory will be the packages you have decided to install.
If you drill into the ‘Client\[Platform]’ directory you will find the .MSP file in this case CU3 for ConfigMgr 2012 R2
Launch a new explorer Window to where the package for you ConfigMgr Client is (Default = \\[Site Server]\SMS_[SMS Site Code]\Client
Within this directory are the x64 and i386 folders respectivly.
For the example, drill into the i386 Folder and create a ‘ClientPatch’ Folder in this directory:
Now copy the MSP into this directory
Repeat this for the x64 directory ensuring you copy the right MSP into the right folder!
Simply update the package for your ConfigMgr Client Agent and your good to go 🙂
Note* – It may be worth performing the last action out of hours as it may interupt a newly initiated build process!
