Update CMTrace for limits

Overview

Ran into this issue again recently at an MDT install. Took a few minutes to realize they had an older version of CMTrace on their Deployment Share and PE media. Was trying to track down several OSD deployment issues and befuddled why nothing was in the log after a certain point. Took a bit to figure out the log viewer was the initial fault. Long story short, CMTrace.EXE from ConfigMgr 2012 RTM is limited to seeing 8000 lines in a log. Microsoft has a KB about it here. I originally ran into this issue a while back with ConfigMgr 2012 RTM and even SP1 with PE media that had the RTM version in it.

Solution

Simple, get an updated version from various sources. If you have ConfigMgr 2012 R2 (or SP1) installed you can get the 32-Bit and 64-Bit editions of CMTrace from the ConfigMgr_Root_Folder\OSD\bin\i386 and x64 folders.Even if you are using ConfigMgr RTM or SP1 you can grab the CMTrace in the R2 Toolkit (or the SP1 toolkit) and update your copies.

For PE media, don't forget to get the 32-Bit or 64-Bit one for your architecture since PE does not have SysWow64 in it. I generally recommend to inject it into the PE media. In MDT do it via the Extra folder under the Deployment Share Properties I also put it in the root of the Deployment Share by putting both 32-Bit and 64-Bit versions there for use in once you have switched from PE to the deployed OS. For ConfigMgr OSD you can do via osdinjection.xml.

Johan Arwidmark has a HOWTO to split the two arches from the toolkit.

CMTrace 2012 Versions

• R2 SP1 - 5.00.8239.1000 
•     R2 - 5.00.7958.1000
•    SP1 - 5.00.7804.1000
•    RTM - 5.00.7711.0

CMTrace Current Branch Versions

• 1511 - 5.0.8325.1000
• 1602 - 5.0.8355.1000
• 1606 - 5.0.8412.1000
• 1610 - 5.0.8458.1000
• 1702 - 5.0.8498.1000

Where'd that XP come from?

Overview

How far along are you in your deprecation of XP? We refreshed nearly 5000 XP systems (even some x64 Edition) during 2013 and have a couple dozen or so still in use along with ~ six Vista systems. Most are tied to lab equipment with no network needs. With that said though, I did not want XP to sneak back in so I asked Cory Becht to develop a script to notify when a new XP system joins the domain. If a new XP system is found, it emails myself and the Global IT leads so they can run down why its around for whatever reason and develop a plan to refresh it to Windows 7.

The email gives some basic info from AD to hopefully give you clues on its whereabouts. It will additionally attempt to do a lookup from DNS to also help track it down.

 Computer LAP1Q2W3E4 running Windows XP Professional is new and is found at:  
   my.domain.local/NorthAmerica/US/Laptops/LAP1Q2W3E4  
   IP Address: 10.10.10.102 AD Site: US  

Simply run as a scheduled task as the SYSTEM account. Be sure to run with 32-Bit cscript if your using a 64-Bit OS. Just update the first several lines for your environment as shown below. We run it once a day.

2:  strEmails = "[email protected];[email protected]"  'separate with semi-colon  
3:  strSMTPServer = "smtpsmarthost.my.domain.local"  
5:  strDomainLDAP = "dc=my,dc=domain,dc=local"  
6:  strDomainFQDN = "my.domain.local"  
7:  strSMTPDomain = "my.domain.local" 'if the from address domain is different  

Theres an Access Database (XP.mdb) that's used to keep track of found systems for performance. Additionally you can modify line 17 for other operating systems. I have one looking for Windows 8 systems.

Download

This script is provided as-is, no warranty is provided or implied.The author is NOT responsible for any damages or data loss that may occur through the use of this script.  Always test, test, test before rolling anything into a production environment.

You can download it from here.

Bonus

We also modified an older version to notify on Servers joining the domain. With thousands of servers we have had cases where a server was not added to backup cycles or some other mishap. This script emails the server support teams so they can setup backup schedules or whatever is needed. Even have used it to catch some systems as having the wrong edition or version of Windows Server.

 Server MDT01 running Windows Server 2012 R2 Standard is new and is found at:   
 my.domain.local/Computers/MDT01  

That script can also be found above. You will have to modify the same parts as above for your environment.

My Image Mule

While attending SCU 2014 (at the Alamo in Denver) someone mentioned using SSD during their presentation and it brought up some conversations in our audience about using SSDs for deployment testing so I thought I would share what we use for our deployment testing. I fondly call these systems our 'Imaging Mules'. What takes over an hour on a fast desktop takes about 15 minutes. Much quicker time frames to test new scripts, wrappers, packages, etc.

For the hardware we took our design workstation standard at the time, a Dell Precision T3600, with 16GB memory, 1TB spindle, and i7 proc and made a few tweaks. We modified the spec by using a 2x250GB HDD RAID0 and removed the nVidia Quadro video card for the cheapest one Dell would put in it, but left it alone otherwise. The 2x250GB is the host OS volume (C) and is Windows 7, and is my primary system even. Once they arrived we bought a bunch of 120GB SSDs, 4 for each system. All the VMs (we use VMWare Workstation), live on a 4x120GB SATAIII SSD RAID0 volume (D). To mount them we obtained several of these adapters. They allow us to mount four 2.5" SSD drives in a 5.25" (optical) bay. The cheap fan died in a couple of them but they are not needed with SSD's so i just unplugged it. For the PERC H310 we had to get another cable to support the SATA drives.

Its pretty spanking fast. Doing some testing I got the following read speeds. These are raw reads and I did not perform any write tests unfortunately. If I have to rebuild that volume I'll do some RO and RW test and update this blog post. Taking over an hour deployment task sequence down to 15-20 minutes is enough results anyhow!

RO Speed	Model	Storage Configuration
142.5MB	Dell Precision T3600	1TB Spinner
221.4MB	Dell Precision T3600	2x250GB Spinners RAID0
1.7GB	Dell Precision T3600	4x120GB SSD RAID0

The 1.7GB is from Samsumg 840 drives. We have some kingstons that gived 1.1GB read. I've had over a dozen VMs all deploying concurrently with little lag. Note that I'm just doing deployments so the 480GB volume is more then enough since we generally dont put user type data in them. Additionally for the host OS I moved TEMP, TMP, and swap to the SSD RAID0. All in all, you can build a super fast image testing box for deployment testing pretty reasonable.

I've since found an adapter that holds six drives and put that into my GENTOO server at home. 

Task Sequence and System Restore

This is an old one (2010) that I don't think many people know about as I was asked by some people recently. When deploying an asset via OSD, System Restore is running so anything that requests it such as Office will get a snapshot. MDT has mechanisms to disable and restore however OSD does not.

I disable System restore during capture then turn it back on as a final step during deployment. Its done for performance as the deployment is sped up greatly as the OS doesn't do snapshots. I actually have had a person do a System Restore back to within the TS, messy to say the least. So my solution is to disable it then re-enable it.

As mentioned previously, I do a Build and Capture TS that installs the OS WIM, does a few things, patches it and captures it each quarter. One of the "few things" I do is to disable System Restore. Disabling it in the B&C also keeps the WIM used to deploy smaller for easier replication. It is the first thing ran after the 'Setup Windows and Configuration Manager' step.

During a deployment TS, it is one of the last things to be ran, I have it before USMT.

You can find the Enable Script here and the Disable script here over at the Script Center.