Recently, I upgraded to the new MDT 6.3.8450.1000. It was a fresh install of the new MDT product in which I created an entirely new MDT share for our Windows 10 build. I had done an upgrade to the other MDT share that contains the Windows 7 builds, and it busted all of them at which point I had to do a restore.
After creating the new task sequences, applications, drivers, OS, and packages, I went to capture my first Windows 10 image and got the error below.
The third line down was the key to the error. I went in and looked at the ZTIUserState.wsf and saw this line:
sScanStateFolder = oEnvironment.Item("DeployRoot") & "\Tools\" & sUSMTArchitecture & "\" & sUSMTVersion
I went to the MDT deployment share and under it to tools\x64\USMT5. There was nothing in that directory. I then looked at tools\x86\USMT5, and there was nothing there either. It was evident that this was the cause. To fix this, I needed to download the latest WADK, which also required uninstalling the current version first. Once it was downloaded, I checked off the User State Migration Tool (USMT) option. Once it completed, I copied over the USMT tool x86 and x64 from
C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\User State Migration Tool\x86
C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\User State Migration Tool\amd64
to the following directories
%MDTDeploymentShare%\Tools\x86\USMT5
%MDTDeploymentShare%\Tools\x64\USMT5
Once I did this, the task sequence can now capture an image with no problems.
While recently writing an MSI uninstaller script, I needed to be able to associate the GUID with the applications name. In the process, I was finally able to associate the MSI files inside the Installer folder with the application.
You may wonder why you want to know this. Most of this is probably just for general knowledge, but there are a couple of instances I can think of on why you might want to know. For one, I used it as described above. You may also want to know this if you are checking to see if the MSI is available to do an uninstall or a repair.
The MSI and MSP files inside the %WINDIR%\Installer folder are associated with the installed application or update in the following registry location:
The screenshot below shows an example of the unique MSI filename in the %Windir%\Installer directory associated with the installed application. The association is made under the LocalPackage.
I am working on the Windows 10 image, and part of this project is converting to UEFI. We do have several older systems that are still in production because systems that are used for temporary or loaner aren't as important to keep up-to-date. I use the oldest model system when creating a reference image so I am sure the image will work across all models.
I first started with a Dell Optiplex 990 and quickly realized it was not compatible with Windows 10 UEFI because of missing BIOS features. I then moved up to a Dell Optiplex 9010, and it included secure boot. Once I set the BIOS for UEFI and rebooted, there was no more screen. The monitor was blank. The first thing I tried was turning off the machine, unplugging the power cord, holding in on the power button for 15 seconds, removing the battery and holding in on the power button for 30 seconds, and then reinstalling the battery before turning the machine back on. This did not reset the BIOS, and the screen was still blank.
The next thing I did was to remove the DVI cable. It was replaced with the VGA cable and was plugged into the built-in motherboard video port. When I powered on the system, I got the following screen to display.
The instructions provided do not work. The video card I experienced this with was the AMD Radeon HD 6350.
What I did to resolve this was to completely remove the video card, connect the VGA cable, and then power the system up. After that, I got the following screen.
Once I got this screen, I was able to go into the BIOS. It ended up being two settings in the BIOS. The first was the Enable Legacy Option ROMs. It must be turned off for the secure boot to be enabled. It was this option that actually caused the screen to be blank when using the video card.
The second option is the Secure Boot Enable. To use this, Enable Legacy Option ROMs has to be turned off.
Once I set these back to the defaults, the system was then able to be boot up and be displayed on the monitor using the DVI video card. It is not the computer if it is an Optiplex 9010 or higher. It is the video card that cannot support the secure boot in Windows 8 or higher due to the lack of UEFI Option ROM drivers as described by Dell and ZDNet. The solution would be to replace the video cards that can support the UEFI Option ROM drivers.
When I installed the new MDT 6.3.8450.1000 to build the deployment package for Windows 10 1709, I ran into issues with the operating system deployment. In the process of building out the new task sequence, I also decided to convert over to UEFI. The OS was laying down, but it was installed on the wrong drive letter, D: instead of C:. After trying many things, I finally decided to abandon the Format and Partition Disk task sequence provided by Microsoft and create my own using PowerShell.
The first step of this is to create the text configuration file. I could have created the file and had the build point to it, but I would rather PowerShell do this. After researching the failed build from other issues, I found it created the following drives listed below:
Boot (EFI) with the drive letter W:
(MSR) with no designated drive letter
Windows (Primary) with the drive letter C:
Recovery (Recovery) with the drive letter E:
To achieve this, I use two task sequences in MDT as shown below,
The first task sequence consists of the PowerShell one-liner as a Run Command Line shown below. The one-liner creates the DiskpartHDD.txt file on the WinPE bootable drive (X:). The numbers I used for the sizes came from MDT.
This is the PowerShell one-liner within the task sequence:
As for the Diskpart task sequence, I used the following Run Command Line task sequence:
This is all that is required for creating the partitions. I commented out the ones provided by Microsoft and it now assigns drive C: for the Windows operating system.
As often as Java must be updated, I wanted to have an auto installer that would make the update a breeze. The way this installer has been written is it will first determine if the system is x86 or x64. At that point, it will uninstall the old version first and then install the x86 if the system is 32-bit, or it will install the x86 and x64 versions if the system is 64-bit. The parameters are the same for both 32-bit and 64-bit versions so you can define the parameters once.
When a new version is released, all you need to do is swap out the installer executables and update the package in SCCM. The script will find the appropriate executable associated the architecture, as Oracle includes the architecture within the filename.
You can download and view the installer code from my GitHub site.
I recently encountered an application that uses the Inno Setup installer. Part of my process when I deploy an application is to also create an uninstaller. While creating the uninstaller, I decided to make a function for uninstalling Inno Setup installed applications.
The way I have written this function is that you need to use the exact name as displayed in the add/remove programs for the AppName parameter. The function will then query the Add/Remove programs registry entries to get the quiet uninstall string and execute it.
You can download the function from my GitHub site.
While building out the Windows 10 reference image task sequence, it dawned on me that I should be making sure the latest Dell Application Component Updates are installed. Since this is a reference image, the system drivers being up-to-date is not essential to me because they will be stripped during the Sysprep process. This does require that you already have the Dell applications installed before executing this one-liner.
I devised this one-liner that can be implemented as a command line task sequence to check for the latest application component updates only. To limit this down to just application component updates, you will need to open the Dell Command | Update GUI application to create an XML file to reference from the command line. Once in the GUI app, click on the Settings icon. Click on Update Filter. Under Recommendation Level, I checked everything. Under Update Type, I checked Application Software. Everything else is left unchecked. Configure every other settings tab the way you want. Now click on Import/Export and click Export. Export the XML to the desired UNC path in which the one-liner below can access. You can also download the XML file I use from my GitHub site.
As for the one-liner below, update the <UNC Path> to the location where the Applications.XML file is located. It does not need to be called Applications.XML. That was my choice.
Putting this into MDT or SCCM is easy. Once you have the one-liner customized and tested, copy and paste it into a Run Command Line task sequence as shown below. That is all it takes to implement this.
Recently, Dell released the BIOS updates covering systems starting with the Intel Family 6 Model 42 and later processors. This is the first part of the patching process. The second part is to apply all windows updates, which I also included all optional updates. That was my personal preference. The third step is to apply the appropriate KB4088878 patch.
The first two systems, Dell Optiplex 990s with Windows 7 64-Bit, I did these patches on were successful. GRC's InSpectre tool was executed and returned the following.
The next two failed. These systems were Windows 7 32-Bit installed on Dell Optiplex 990s with 64-Bit processors. The BIOS was patched with the latest A23 version Dell had published. The windows updates were all installed. When the windows6.1-kb4088878-x86_7512ab54d6a6df9d7e3d511d84a387aaeaeef111.msu was applied, the following crash screen appeared when the OS booted back up.
One tactic I tried was to configure the registry to clear out the page file when the system shuts down by changing the value of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\ClearPageFileAtShutdown to a 1. The next thing I did was to boot the system into safe mode to execute the patch. I got the following message.
In conclusion, the only solution is to have the hardware architecture match the OS architecture. If they match then applying the appropriate patch will be successful.
Here is a note on patching. Applying the latest BIOS does not pass the GRC Inspectre test. The Microsoft OS patch must also be applied for the system to pass the test.
Ever since the Spectre and Meltdown issues arose, we have been waiting on patching, at least reliable patching. Microsoft has taken it on itself to patch systems for the vulnerability. ExtremeTech wrote an excellent article on Microsoft's solution which gave me the thought to write a script for telling which systems are compatible. To determine the minimum family and model compatible with the patch, I used the data from this Intel page that associates family and model to the microarchitecture code name. I converted the family and model from hexadecimal to decimal. That is how I came up with the bare minimum being Family 6 Model 42.
NOTE: The ExtremeTech article includes the Haswell processor as also being compatible. We do not have any Haswell processors in my environment, so I am not able to know what the minimum family and model are for Haswell. If you do have Haswell processors in your environment, I would appreciate you running the following PowerShell cmdlet and reply here with the output so that I can include it in the script. Thanks.
(Get-WmiObject win32_processor).Caption
The script can be executed using the new Scripts tool in SCCM, which is how this was done in my environment.
While working on the Windows 10 upgrade project, I ran into a situation which I needed the information from an MSU file for the task sequence. Specifically, I needed the KB number. The first thing I did was to try and use the same method used in retrieving info from MSI and MSP files by trying to query the database. That does not work with an MSU file. An MSU is nothing more than a zipped up file of several files. In each MSU file, there is a *Properties.txt file which contains all of the info.
This script contains the function Get-MSUFileInfo which will retrieve all available info on the MSU. I designed it so that it creates an extracted folder in the relative path of the script. The MSU is then extracted to that extracted folder. Next, the script will read all of the contents of the *Properties.txt file into an object. Finally, the extracted folder is deleted.
Here is an example of the script retrieving the info into an object:
You can download the script which contains the function from my GitHub site. I put the function into a full script for easy testing in your environment.
Below is a video on how to add ShareThis to Blogger. It is a very easy process. Apparantly the process has changed since other instuction pages were created. I spent a few hours trying to figure out why injecting the javascript into the HTML code was not working. I cover how to implement both the sticky and inline buttons. As you will see, the bar works on my blog with no problems. Also, at the end of the video, it does show the sticky share buttons turn off. I turned them back on and they are working perfectly.
Here is a picture of this blog page after it was implemented:
This script function will uninstall an MSI installed application by specifying the GUID and the switches. I have included the ability for the script to query the registry for the name of the application to display for user output. The function also will exit the script if there was a failure.
NOTE: The script uses write-host for user output so that if it is manually executed, the admin will be able to easily see if it was successful by success being in yellow, not installed in green, and failure in red. Write-Host is the only option for being able to display in multiple colors and the ability to not start a new line when it displays "Uninstalling Java 8 u 161....." as it waits for the exit code of the uninstall to show one of the three outputs above in the designated colors. If you do not want to use write-host for this, you are welcome to rewrite the code, which is being openly shared.
Here is an example of the function running in the script provided below. This is not in color because it was executed within PowerShell Studio. This is in a script format so you can easily test this out before using the function in another script.
Here is a function that will uninstall an MSI installed application by the name of the app. You do not need to input the entire name either. For instance, say you are uninstalling all previous versions of Adobe Reader. Adobe Reader is always labeled Adobe Reader X, Adobe Reader XI, and so forth. This script allows you to do this without having to find out every version that is installed throughout a network and then enter an uninstaller line for each version. You just need to enter Adobe Reader as the application name and the desired switches. It will then search the name fields in the 32 and 64 bit uninstall registry keys to find the associated GUID. Finally, it will execute an msiexec.exe /x {GUID} to uninstall that version.
Update:
This is the third revision of the function that will uninstall an MSI by its application name. The last revision was an efficiency improvement. This revision adds the ability to uninstall all instances of an application. For instance, if several versions of Java 8 are installed, this function can uninstall all of them by just defining Java 8. The function covers both x86 and x64 based apps. The previous versions of this function could only uninstall one app at a time. This will uninstall all of them.
Here is a visual on the script uninstalling multiple versions of Java 8.
You can download the code from my GitHub site located here.
As we all know, Mozilla Firefox is not the easiest application to deal with when it comes to deploying it in an enterprise environment. I have finally taken the time to write a PowerShell script that will install it using the executable provided by Mozilla.
This installer will kill all instances of firefox, execute the uninstaller helper file, and then delete the programdata folder. Next, it will run the Firefox installer, create the autoconfig file and the Mozilla config file. The autoconfig.js file will point firefox to the mozilla.js file. I have written the script, so it creates and injects the configuration information within the CFG files. If you do not want this, you can comment out the New-AutoConfigFile and New-MozillaConfig lines. I also created a Configuration.ini file to configure the desktop shortcut during the installation.
Also, we still have some 32-bit machines, so I set up the script and file structure as shown below with the individual executable in the appropriate architecture folder.
You are installing RSAT in a build, and you want to check if it is installed if it is included in the windows updates. Recently, there has been the issue in Windows 10 where RSAT cannot be found in the Windows Features. It is also not found in the Win32_OptionalFeature. To work around this, I have this one-liner incorporate checking for the feature first and if that turns up nothing, it then checks for the active directory module, which exists if RSAT has been installed. It will return an exit code of 0 for success and 1 for failure which can be used to either pop up a warning or kill a build if not present. This has been tested on both Windows 7 and Windows 10.
As you have probably seen recently in my latest blog entries, I am working on a bunch of PowerShell one-liners to do away with the actual scripts and be able to implement the PowerShell process as a command line task sequence.
This one-liner will add the necessary registry entry to allow for a user to run a PowerShell script as administrator. This has been tested in a task sequence.
Recently, I have been revisiting our task sequence for our base build. One of the tasks it does it to set the PowerShell executionpolicy. Yes, we do have a GPO that does this, but this being the base build that generates the golden image, GPOs are not applied during the build process.
Originally, I had the simple command line task that implemented the following command line: powershell.exe set-executionpolicy RemoteSigned. I know that should work with no problems, but I wanted to have PowerShell verify that was set. To do that, I created this one-liner that checks if the executionpolicy is set to the defined policy specified in the variable $Policy. All you need to do is change the value assigned to the $Policy variable. If it does not match that, then it sets the executionpolicy and checks again. If it is set to the defined policy, then the script returns an exit code of 0, otherwise, it returns an exit code of 1 which will fail the build.
While writing this package for the BIOS updates on our systems to negate the Spectre and Meltdown, we decided we wanted all laptop systems to be docked. This is an extra precaution we are taking, along with deployment during the early hours of the morning, to minimize the possibility of the BIOS update being interrupted during the installation process by human error.
The first thing I found that designated if a system was docked was this registry key supposedly changing when a system was docked.
I quickly realized this may have worked a long time ago, but it does not work anymore. The next thing I did was watch the event viewer logs. The only changes I noted there were with the ethernet when docked. The next thing I checked was the device manager and Voilà . The device manager changes when a laptop is docked. Specifically, the human interface devices add HID-compliant devices. I really thought the changes would be under system devices. Under the Human Interface Devices, I only included the devices that are labeled HID-compliant, in the HIDClass, are not vendor defined, and where the status of each filtered device is not OK, meaning it is not docked. This was all put in a one-liner that returns an exit code of 1 if any of the devices do not exist.
This one-liner is being used in the task sequence. If a return code of 1 is returned, meaning the system is not docked, the task sequence fails.
NOTE: For the systems this has been tested and run against, they are all Dell Latitudes. I do not have access to any other vendor systems to test against. If your company uses another vendor, you will need to possibly modify this script, or it may not work the same way. Also, it has been verified that this is different on varying models of Dell systems. I received a response on one of the Facebook groups saying he had to make some changes to the code for the Latitudes his company uses.
Over the past three years, I have not had a need to use the Microsoft PowerShell Gallery on the Windows 7 machines. While working on the Spectre/Meltdown issue, it finally hit me that I needed to use it on the Windows 7 machines. It was kind of hard to find clear and concise instructions on installing it on those machines. Windows 10 is a breeze, but there were extra steps. Luckily, all of the Windows 7 machines already met the required criteria. The following are the requirements and steps you need to take to use the PowerShell Gallery on Windows 7 machines.
Requirements:
Windows .Net Framework 4.5 or later
PowerShell 3.0 or later
Once you have these requirements met, here are the steps to gaining access to the PowerShell Gallery in operating systems earlier than Windows 10:
Download the PackageManagement_x64.msi and/or PackageManagement_x86.msi from the Microsoft Download Center. Place the x86 and x64 versions in the same directory as the PowerShell script.
Deploy the appropriate PackageManagement version to each machine
Now that Install-PackageProvider cmdlet is available, execute the following Install-PackageProvider nuget -force -verbose
You will now have access to the PowerShell Gallery using the install-module cmdlet.
The script for installing and configuring the system to access the gallery is located on my GitHub site.
While writing the solution for a secure and safe deployment of BIOS updates, I had to come up with a one-liner to backup the Bitlocker recovery password to a file named <computer name>.txt in a secured UNC path. Yes, we already have MBAM, but I wanted an extra layer of safety in the event something went wrong when applying the BIOS updates to the Bitlockered machines, thereby requiring the recovery password. Also, there are a lot of admins who work at companies which do not have products such as SCCM and MBAM. The reason the PowerShell Bitlocker CMDLETS were not used is that this is designed to run on Windows 7, 8, 8.1, and 10 operating systems.
To use the one-liner below, you will need to update the portion in yellow to the UNC path of your desire. This can be used deployed through SCCM to machines to backup their recovery keys. I used this in a task sequence.
I needed to install .Net Framework 4.7 on all systems. We no longer manage windows updates via SCCM, so we needed to deploy it as an application. I downloaded the two MSU files, 32-bit and 64-bit, from the Microsoft Update Catalog.
This script checks the system architecture and then knows which installer to execute. I have included the return codes for reboot required and already installed. The script converts those to normal SCCM return codes, 0 and 3010.
<#
.SYNOPSIS
Install .Net Framework 4.7
.DESCRIPTION
This script will install .Net Framework 4.7 using the MSU file. It is written to accommodate both x86 and x64 versions. The script will also convert the WUSA.EXE return codes to standard SCCM return codes.
.NOTES
===========================================================================
Created with: SAPIEN Technologies, Inc., PowerShell Studio 2017 v5.4.143
Created on: 9/15/2017 10:45 AM
Created by: Mick Pletcher
Filename: installDotNet47.ps1
===========================================================================
#>
[CmdletBinding()]
param ()
function Get-Architecture {
<#
.SYNOPSIS
Get-Architecture
.DESCRIPTION
Returns whether the system architecture is 32-bit or 64-bit
.EXAMPLE
Get-Architecture
.NOTES
Additional information about the function.
#>
[CmdletBinding()][OutputType([string])]
param ()
$OSArchitecture = Get-WmiObject -Class Win32_OperatingSystem | Select-Object OSArchitecture
$OSArchitecture = $OSArchitecture.OSArchitecture
Return $OSArchitecture
#Returns 32-bit or 64-bit
}
function Get-RelativePath {
<#
.SYNOPSIS
Get the relative path
.DESCRIPTION
Returns the location of the currently running PowerShell script
.NOTES
Additional information about the function.
#>
[CmdletBinding()][OutputType([string])]
param ()
$Path = (split-path $SCRIPT:MyInvocation.MyCommand.Path -parent) + "\"
Return $Path
}
function Install-MSUFile {
<#
.SYNOPSIS
Install Windows Update
.DESCRIPTION
This function installs windows update MSU files.
.PARAMETER FileName
Name of MSU file
.NOTES
Additional information about the function.
#>
[CmdletBinding()]
param
(
[ValidateNotNullOrEmpty()][string]$FileName
)
$RelativePath = Get-RelativePath
$Executable = $env:windir + "\System32\wusa.exe"
$Parameters = $RelativePath + $FileName + [char]32 + "/quiet /norestart"
$ErrCode = (Start-Process -FilePath $Executable -ArgumentList $Parameters -Wait -Passthru).ExitCode
Return $ErrCode
}
$Architecture = Get-Architecture
If ($Architecture -eq "32-Bit") {
$ReturnCode = Install-MSUFile -FileName Windows6.1-KB4019990-x86.msu
} else {
$ReturnCode = Install-MSUFile -FileName Windows6.1-KB4019990-x64.msu
}
#Exit Return Codes
#2359301 -- Reboot Required
#2359302 -- Already Installed
If ($ReturnCode -eq 2359301) {
$ReturnCode = 3010
}
If ($ReturnCode -eq 2359302) {
$ReturnCode = 0
}
$ReturnCode
Exit $ReturnCode
I have been coming to the Microsoft Ignite convention since it's inception in 2015. The first conference held in Chicago had a lot of fallacies. It was the first time Microsoft had combined the conferences into one. Since then, Microsoft has steadily improved. Atlanta was significantly better and this year's conference in Orlando was awesome! I am sharing my experiences on the conference and what I suggest might be good for first-timers. It is overwhelming the first time you attend. It was for me the first year and I have had first-timers tell me the same thing.
Registration
Registration is pretty straightforward. It requires paying up front when you register. This is the website for Ignite registration. If you are a Microsoft MVP, registration will be cheaper and you can register earlier.
MVPs & Ignite
If you are an MVP, Registration will be cheaper. You will also have the chance to submit a proposal for speaking at Ignite. There will be a pre-day conference for MVPs while also getting the MVP sticker for your badge.
Boarding
When Microsoft opens up the registration for Ignite, they will have a set number of hotels reserved for the conference. There are pros and cons to this. The first year in Chicago, the set of hotels they had reserved were all very expensive. Personally, I appreciate the firm I work at paying my way each year to the conference, so I try to be very conservative on my charges. I ended up using AirBNB that year and it was a great experience as I was close to the McCormick Place and the entire week cost less than one night did at the select hotels. Atlanta, the hotels were nicely priced, so I stayed in one of the select hotels. Finally, Orlando, I ended up staying in a hotel that was close to a select hotel. I did not like the billing policies of the hotels in Orlando, which I will talk about later.
If you stay in select hotels, a shuttle, which is a full-size motorcoach, comes by to pick you up in the mornings and take you back in the evenings. It does not run midday.
As for booking your hotel, if you decide to use a select hotel and register during your Ignite registration, here are some facts about it:
You are only reserving it. You will have to pay for the room when you arrive. Some of the hotels will allow you to pre-pay, but as with my experience in Orlando, I did not like how they handle pre-payment. Several of the hotels I called send an authorization form to you and have you fill out the credit card information to fax back. When I questioned what happens to that form, they permanently file it. Yeah, I don't want my credit card information permanently filed. They don't take credit card information over the phone either. That is why I ended up using Priceline to book my hotel near one of the select hotels so I could walk over and take the shuttle.
While reserving on the Ignite registration site, if your card expires before the conference, it will not let you register for a hotel since it is only reserving the room. It requires the card be valid past the date of your stay.
Some of the select hotels do have activities going on in the evenings.
Food and Drink
Breakfast and lunch are provided at Ignite. Since the first year there, the food has greatly improved. I still hear complaints about it but with the vast size of the conference, you can't expect to feed 23,000+ with restaurant style accommodations. This is the typical lunch tray. They do accommodate for food allergies and specific diets such as vegan. Supper is not served, but there will be food stands set up a few times during the conference late in the afternoon that I thought was more than ample for supper. There are refrigerators setup throughout the conference that has lots of canned and bottled drinks free of charge. There are also tables with snacks such as cracker packs.
Sessions
The main reason you are coming to Ignite is for the sessions. They provide you with continuing education on new ideas and new products, while also providing training on existing products. The sessions vary widely. They consist from beginner to advanced. The best thing is to log in to the Ignite registration website and go through the list of sessions to see what you want to attend. As you select them on the website, they will also be able to sync with the Ignite mobile app. The mobile app can add the sessions you choose to your calendar for alerts. You are likely thinking, what can possibly be the downside to the sessions. Size of the conference is number one. The conference area is so big that you may not have time to get from one session to another. Some sessions are closed after the session has begun. There is often more than one occurrence for a specific session allowing you to get to that session in the event the first one coincides at the same time. One thing Microsoft did for the sessions that has helped a lot is live streaming that helps with not having to physically go to a session and be able to sit there and watch it on your smart device.
Microsoft also had hands-on labs that are great for getting hands-on experience with apps that you may want to check out or need more time with.
Attire
People vary vastly in their attire. It goes from business casual to casual.
Vendor Stands
The vendor stands open up on Monday at 12:00 pm after the Keynote. There are lots of vendors there. There are giveaways from motorcycles to shirts. It is a great place to approach vendors for specific questions on their products. If you are having problems with a product at your company and have questions, most of the vendors have a technical person there to answer them for you. At the least, they can put you in touch with the right person at their company which can answer your question(s). Part of the vendor stands is Microsoft. This means you can go to them for questions about Microsoft products.
After-Hour Vendor Parties
Some of the vendors hold after-hour parties, and from my experience, some are extraordinary. They go all out. The parties are not held at the conference center. They are held at different locations. For instance, one party I attended was in an airplane hanger. Another was at the John Hancock Signature Bar. The problem a lot have is knowing about the parties.
There are a few ways to learn about them. The first is to go to the vendor tables and some will have party sign-up sheets. Some will post on Twitter with the hashtag #MS_Ignite. Another is to follow Harjit Dhaliwal on Twitter. He posts a lot of the parties taking place. The times and length of the parties vary. If the party is held at a facility that is outside of walking distance, the vendors often supply transportation to and from the party.
Celebration
The celebration is a lot of fun. The first year of Ignite, the celebration was a total disaster. There were 30 food tables for 20,000+ attendees. Yeah, it took up to an hour for a small serving of food. Since then, Microsoft has done very well. The last two celebrations have been great. The celebration in Atlanta was held at the Centennial Olympic Park. It was a lot of fun. The celebration in Orlando was held at Universal Studios and it was fantastic! They cordoned off part of the park for the celebration.
For the celebration, you can bring a significant other with you. The cost is $150 and is booked when you book for Ignite. One thing I learned this last year was that there are only 1,500 openings for a significant other. Apparently, others did not know this either as I saw one attendee walking around the conference with a piece of paper on his back asking to purchase an armband for his spouse. My suggestion to you is to book fairly early if you want to bring someone with you to the celebration.
Navigating the Conference
It takes time to get accustomed to the enormous area of the conference. There are Microsoft employees standing around to help you find where you are going. There will be a LOT of walking. Bring comfortable shoes. It is a must! Last two years, I logged 29 miles in Atlanta and 34 miles in Orlando. The Ignite app will help you greatly in getting around the conference.
Connections
Microsoft Ignite is just as much social as it is educational. You are likely to get a lot of connections with other IT professionals. If you have business cards, bring your box with you. I learned this last year that taking a picture of someone's badge with the iPhone 7 Plus also reads their QR code. That was pretty cool to learn by accident.
Finally, 1E interviewed me at Ignite and here is the video on how to get around.
This weekend, I listened to Security Now's KRACKing WiFi podcast Episode 633 where they discussed the TPM vulnerability. Finding out exactly what to look for was tedious. I finally ran across Lode Vanstechelman's blog entry that told exactly what to look for. The only thing it does not address is using SCCM to find vulnerable systems. Since you are looking for specific TPM manufacturer IDs and Versions, SCCM is a great tool to find the systems across a large network.
As listed on Lode's site, you are looking for Manufacturer ID 1229346816. If that ID is present, then the following versions are affected:
4.00 to 4.33
4.40 to 4.42
5.00 to 5.61
6.00 to 6.42
7.00 to 7.61
133.00 to 133.32
NOTE: The firm I work at did not have any systems that met the manufacturer ID criteria. The WQL below is written without the ability to test it. Treat it as a template. I would appreciate if you could leave feedback on whether it needs to be modified or not.
Here is the WQL query:
select SMS_R_System.Name, SMS_G_System_TPM.ManufacturerId, SMS_G_System_TPM.ManufacturerVersion from SMS_R_System inner join SMS_G_System_TPM on SMS_G_System_TPM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_TPM.ManufacturerId = 1096043852 and ((SMS_G_System_TPM.ManufacturerVersion >= "4" and SMS_G_System_TPM.ManufacturerVersion <= "4.33") or (SMS_G_System_TPM.ManufacturerVersion >= "4.40" and SMS_G_System_TPM.ManufacturerVersion <= "4.42") or (SMS_G_System_TPM.ManufacturerVersion >= "5" and SMS_G_System_TPM.ManufacturerVersion <= "5.61") or (SMS_G_System_TPM.ManufacturerVersion >= "6" and SMS_G_System_TPM.ManufacturerVersion <= "6.42") or (SMS_G_System_TPM.ManufacturerVersion >= "7" and SMS_G_System_TPM.ManufacturerVersion <= "7.61") or (SMS_G_System_TPM.ManufacturerVersion >= "133" and SMS_G_System_TPM.ManufacturerVersion <= "133.32")) order by SMS_G_System_TPM.ManufacturerId
With the advent of mass deployment errors such Emory University and CommBank, there needs to be a master kill switch. I also read several months ago about a University in one of the Scandinavian countries that did the same thing. The last two years at Microsoft Ignite, I have also talked to SCCM professionals who experienced the same thing, one in Oklahoma at an oil company and another in Michigan at a financial services company. The last company with more than 100,000 systems abandoned SCCM for imaging purposes and went to MDT to assure this would never happen again.
Over the past three years, I have contemplated a new method for resolving this. At first, I started writing a tool that would shut down all pertinent services on machines such as windows installer and would kill certain task sequences, along with several other things. While having partially written this, a much easier solution came to my mind. This solution is very basic but is also most effective.
I also want to point out one thing here. My solution does not compete with Adaptiva's. Adaptiva has a much more robust solution, but if you choose to not use their solution, this solution can do a good job at stopping an image or even an application from installing.
The solution I have come up with uses a simple text file. In the task sequence list, you will want this to be before the system partitions are wiped. I took a screenshot of this in MDT, which you obviously would not need this fuse unless you have a team that images machines and you want the process to stop right now. In SCCM, you would make sure it is before the system reboots into WinPE to wipe the partitions.
As you can see from the pic, I used a command line task sequence. I used a PowerShell one-liner to test if the file is present. If it is not present, then it returns an error code 1. This error code kills the build.
The file I created is an empty text file which I removed the .TXT extension.
When I started my image, the picture below shows what happened when the file was not present.
This could also be incorporated into a software deployment in the event you accidentally deploy an application and realize it needs to stop NOW! If you deploy apps like I do using script files (PowerShell), you could add a line in the script to check for the file before proceeding. This would kill the installation if it has started, but not reached the point of installation yet.
It is obvious that if the admin does not realize there was a mistake made, the image will continue.
Recently, I built and published the Dell driver update script that may or may not require a reboot. I instituted the script as a task sequence in MDT and then made the following task sequence a reboot. Thinking about it, the reboot may not be required and therefore that would be a waste of time. To get around this, I decided to investigate a conditional reboot.
In order to institute this, I used the standard Restart Computer task sequence and I added conditional parameters to the Options tab shown below.
Here is a screenshot of each of the three keys:
I have tested this by injecting the specified registry keys and these work great. One thing you will encounter when creating these to test just for the existence of the key without a value is a requirement for a value as shown below. I entered a blank space in that field and it worked.
There is one additional attribute to look at and that is a pending reboot via the configuration manager client. It is the following:
So far, I have not been able to get this incorporated as a condition using a WQL query. Apparently, you can only use WQL for the class root\cimv2 and no others. I am likely going to have to create an additional task sequence that creates an MDT/SCCM variable with a boolean value using PowerShell. That is on my list.
