We currently have a working setup of MDT linked to WDS. When I PXE boot, everything works as expected, and the new computer deployment succeeds.
However, I am trying to see if we can push the build remotely with PsExec or PDQ Deploy. I've got it mostly working by pushing this command:
\\domain.org\dfs\MDT\Scripts\LiteTouch.vbs /skiptasksequence:YES /skipcomputername:YES /rulesfile:\\domain.org\dfs\MDT\Control\CustomSettings.ini /SkipDomainMembership:YES /SkipApplications:YES
The LiteTouch launches, the computer reboots into WinPE, and it begins - but it fails right when it should do "Install Operating System", giving error
FAILURE (5456): Unable to determine Destination Disk, Partition, and/or Drive. See BDD>LOG for more information. Litetouch deployment failed, Return Code = -2147467259 0x80004005
I tried a few different things I found with changing the Install Operating System step and the Format and Partition step, no dice. Fails at this point every time.
All I want is 1 partition for the whole drive for the OS to use. We've had OSDisk as the name but that doesn't even matter if it is important. And I use a script called UserExit.vbs that keeps the name of the machine when it rebuilds.
All relevant servers are Windows Server 2016, version 1607.
All client OSes are Windows 10 Enterprise, version 1507.
Screenshots
CustomSettings.ini
I tried to include all the relevant code and screenshots above, slightly anonymized with domain.org. Please let me know if there is any more information needed.
In my lab I have the latest MDT build 8443 which provides better support for deploying Win10 1607 and Server 2016. It's recommended to upgrade your MDT 2013 U1 to the latest version, the download link can be found here.
For your questions, you can give the System Partition size 350MB, mark it as a Boot partition, and create the OS partition with the rest disk space. In my test I just keep with the default configuration like below:
The System Partition will be hidden automatically and the OS partition will get C: drive latter. (During WinPE the System Partition is assigned a V: drive letter but it will be removed later)
Edit: Now I can just reproduce your issue in my lab as the below error shown:
I add "Format and partition disk" step under the "Refresh Only" group to enforce this step be executed during the TS. After configuring this, the issue appeared subsequently. If I run the same WMI query as the log stated it returns empty result. The VolumeSerialNumber(VSN) in the query is created during the partition creating and formatting process and will change each time when the disk is formatted. However, in this query the VSN used is still the previous one (before formatted) so the result will be empty.
SELECT * FROM Win32_LogicalDisk WHERE Size = '41996513280' and VolumeName = 'Windows' and VolumeSerialNumber = 'XXXXXXXX'
Commonly, when you launch the LiteTouch.vbs it will be considered as a "Refresh" deployment. In this scenario by default the disk will not be re-formatted excepted the OS drive. When you launch the TS from WinPE (via PXE or boot media) it will be considered as a "NEWCOMPUTER" scenario and disk will be formatted. These two scenarios are totally different in the deployment behavior and your TS only can be used in the NEWCOMPUTER scenario.
Solution: Do not disable the "New computer only" and "Refresh Only" groups in your TS, remove the "Format and Partition disk" step just like the default TS shown then your deployment should be okay.
Related
My software (with admin priviledges) periodically performs the following query via WMI to know the status of the CPU:
ManagementObjectSearcher searcher = new ManagementObjectSearcher("select * from Win32_PerfFormattedData_PerfOS_Processor");
ManagementObjectCollection collection = searcher.Get();
Suddenly (meaning after months where the result of searcher.Get() was always available) the command started sitting down and throwing an "Invalid query" Exception after a timeout. I cannot say what's changed in the machine before this happens.
I confirmed this error by testing it with tool wbemtest:
The error happens everytime, even after reboot. How can I debug it?
System is Windows 10 x64 IoT Enterprise v1607.
The solution is explained in this article.
Anyway, I still have not understood the reason why the counters may get corrupted. Any comment on this?
I ran into this issue on a Windows 7 machine separate from a network and required to be kept around for various reasons.
At first I thought it was an admin thing (the program runs as a normal user) because system event viewer error 2011 hints at that.
However, it's fixed with this:
lodctr /r
I don't fully understand why, but this article was my source:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/4d574e10-17f5-4599-95d6-2492ede3cfef/wmi-query-from-net-application-cause-2011-error-event?forum=netfxbcl
I have a few VMs in Parallels 11, running several different versions of OS X, for automated software builds.
I recently copied those VMs to a different host, so I'd have a second set to fall back on in case of a hardware failure.
The problem: the copied VMs have the same Hardware UUIDs as the corresponding originals, and that causes a problem backing up the VMs with Time Machine, since Time Machine links backup images to machines by their Hardware UUIDs. If you have two VMs with the same Hardware UUID, Time Machine running in those two VMs will try to write to the same sparsebundle file on the backup server.
I googled the issue and found this: http://kb.parallels.com/en/11197 -- but those instructions don't work for Parallels 11: when you double-click the pvm, it is imported immediately, without asking whether it was moved or copied. When I first imported the copies, Parallels asked me whether the VMs were moved or copied, and I answered that they were copied. The KB article makes it sound like that should have made Parallels assign new Hardware UUIDs to the VMs, but that didn't happen (it did assign new MAC addresses, though).
I'm going to try finding the Hardware UUID in the PVM using a hex search; if I can find it, maybe I can change it manually, using a hex editor. It seems like a very yucky procedure, though, for something you'd think Parallels should handle itself. Is there any better way of doing this? Is this a bug in Parallels 11, or did they deliberately remove the Hardware UUID reset functionality (and if so, why)?
I was able to change it by:
Shutting down the virtual machine
Find the virtual machine bundle located on disk in Finder, right click on it and "Show package contents" on the actual .pvm file.
Then find the config.pvs file inside and open it with a text editor.
Change an arbitrary digit in the <SourceVmUuid>
value
Start the virtual machine
You can then go to:
About this Mac -> System Report -> Hardware
and inspect that the Hardware UUID has changed.
Can we find if our software has been copied in an OS image (windows) and then deployed in another machine. The hardware details do change but it may be due to hardware upgrade or change.
Is there anything at software level which indicates that the OS image has been installed.
P.S the OS install date doesnt change after image deployment.It shows the date of original OS installation date and time and not that of the imaged one.
For example i tried to detect this using service tag,uuid and os install date changes . I thought the hardware and software details combined would result in correct detection. But the os install date dint change and hardware details changed or showed junk value during hardware upgrade . My software will be installed in the os . Then OS will be imaged. I want to detect the imaged installation
If your software is connected to the Internet this is relatively easy to solve. You arrange to 'call home': send occasional packets to a known server address containing enough information to identify the instance.
For this purpose UDP packets serve quite well. You include information about the build of your software, the operating system it is running on, some simple hardware details such as how much memory and disk, the IP address and the MAC address. From the packets logged by your server you will easily be able to tell an original instance from a clone, or an original with updated hardware in almost every instance. You may also be able to obtain highly distinctive information by a detailed inspection of hardware if you have sufficient privilege.
Please note that Windows does exactly this. If an activated copy is found running on a machine that is sufficiently different then it must be re-activated. The definition of 'sufficiently different' is not made public.
Just to be clear, what I'm describing is a heuristic, not an algorithm. I'll assume the original installation creates a GUID, and that a clone carries the same GUID. When you receive packets from installations with the same GUID containing enough information, in practice you will be able to tell the original from the clone in virtually every case. Two clones may start identical but very soon something will diverge: a network IP address, disk free space, active devices.
This may not fill all the requirements of the original question but it will work (it already does) and it's better than nothing.
Generate a GUID each time the computer boots, and include both the current GUID and the history of GUIDs previously generated each time you report to the server.
If a machine's report has a GUID missing, then you know the machine has been cloned and at least one new instance should be generated. You can determine when the cloning took place by looking for the last GUID that is remembered by both instances.
To determine which instance to consider "the same machine" as the original, if this matters, look for changes in the MAC address or computer name. If there is exactly one instance where neither of these have changed since the machine was cloned, that can be assumed to be the original. (If there are multiple instances with the same MAC address, something is badly wrong; bring it to the attention of the system administrators and let them sort it out.)
If none of the current instances has a matching MAC address and computer name, this might mean that the original machine has not been powered back up yet but will be eventually, or that it has been destroyed, or that it is permanently offline and only being used as a template. It could also mean that, by coincidence, the computer name and/or MAC address were changed after the machine was cloned but before the next report.
How best to deal with this depends on the context, but in most cases it would probably be sensible to show the original machine as a separate instance, even if you haven't had a report from it since the cloning took place, and let the system administrator manually delete it if appropriate.
I've recently started seeing this line in my Visual Studio 2005 output window when launching my application:
FTH: (7156): *** Fault tolerant heap shim applied to current process. This is usually due to previous crashes. ***
I've tried turning off the fault tolerant heap using the instructions here:
http://msdn.microsoft.com/en-us/library/dd744764(VS.85).aspx
I'm running Windows 7 64-bit edition, so I have made the changes to both the 32-bit and 64-bit registries, and run the "Rundll32.exe fthsvc.dll,FthSysprepSpecialize" command using both the 32-bit and 64-bit versions of Rundll32.exe.
However, after rebooting I am still getting the fault tolerant heap when trying to debug my application!
This is a real problem since it masks the bug I am trying to reproduce, and it also kills performance.
Does anyone have any other suggestions how to disable the fault tolerant heap?
To disable it for a single application
Go to the HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER versions of
Software\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags\Layers\your_application.exe and
delete the FaultTolerantHeap entry.
From here (actually here)
Set this registry value to 0:
HKEY_LOCAL_MACHINE\Software\Microsoft\FTH\Enabled
You can add the name of your executable to the ExclusionList.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\FTH\ExclusionList
Works for me.
You can edit the application manifest to excluding your program from PCA
see also:How to reset Program Compatibility Assistant for testing
you can clear the list of applications tracked by FTH without stopping this service by following these steps:
Click the Start menu.
Right-click Computer and click Manage.
Click Event Viewer -> Applications and Services Logs -> Microsoft ->
Windows -> Fault-Tolerant-Heap.
View FTH Events.
you will find file named operational by right click and choose clear log,
then you can run you program again and warning message will disappear,
it worked with me without restarting operating system.
On Windows 10 the registry location is:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\FTH
You can remove you executable from the list in:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\FTH\State
or you can run this command from an elevated command prompt
Rundll32.exe fthsvc.dll,FthSysprepSpecialize
You may need to reboot your machine
"Rundll32.exe fthsvc.dll,FthSysprepSpecialize" looks to only clear the list of currently flagged applications. if your application still causes oddities, the FTH should still step in and take over.
as already mentioned:
Set this registry value to 0: HKEY_LOCAL_MACHINE\Software\Microsoft\FTH\Enabled
this should disable FTH for the whole system.
I had to rename the file as well because the registry entries associated with this key were empty of applicable data. I expect that they populate if you have a misbehaving application. But in my case I was debugging my own application within Visual Studio. So in that case, it was my process that was somehow loading the FTH whether the FTH Service was running or not. And in fact I had no applications listed that were previously tagged as misbehaving.
But I had to follow these instructions:
http://billroper.livejournal.com/960825.html
because it wouldn't let me rename the file until I took ownership and made sure I had full control.
I had similar issue when running a Unit test using (Microsoft::VisualStudio::CppUnitTestFramework).
Somehow I had violated some heap allocation, and next time I tried to debug I received the message : "Fault tolerant heap shim applied to current process. This is usually due to previous crashes. " and the debug environment froze.
To get it to work again, I had to remove test case, recompile and add it again and recompile, then I could set breakpoint and step into the test.
Also ran into this. Renaming/deleting AcXtrnal.dll inside Windows\AppPatch seems to work for me. I like how this Microsoft recommended action (which I did first) does nothing.
Windows 7 is caching some of the COM class information. Older OSs didn't do this. After the OS looks up theHKCU\Software\Classes\CLSID\{GUID}\LocalServer32 value, it caches the value, and doesn't look it up again.
When we update our software, we place the new updates in a different directory, and then update the HKCU\Software\Classes\CLSID\{GUID}\LocalServer32 value to reflect the new path. The next time the software runs, it will use the latest files if running under older Windows OSs. However, on Windows 7, it will continue to use the older file, until the OS is rebooted.
I ran process monitor, and discovered that under Windows 7, it never reads the registry key again, after the first read. On older OSs, it reads that key every time.
My question is: Is there any way to force Windows 7 to re-read the LocalServer32 information from the HKCU hive each time a new out of proc COM object is created?
I have only been able to solve this problem by...
1: Stopping the Process
2: explicitly unregistering using regsvr32 the library ( or exename /unregserver)
3: Registering the new component
4: Starting the process back up.
I would suspect that it is the Un Reg part that is failing for you. If you are just changing the registry key directly then you should call RegSvr32 /u instead.
Also make sure the new directory location is the current directory when you call RegSvr32.
Note that I have always stopped the process and then unregistered, this is probably a significant detail.
As this is a top result in Google for this narrow-ish problem, I thought it would be valuable to add my troubleshooting outcome for this problem.
I found this response on SO: C# : How to change windows registry and take effect immediately
And linked solution from that answer: Registry Watcher C#
Both of which seem viable options for managing changed keys without forcing a reboot. For us (like the OP) this was when installing updates. For us (possibly unlike the OP) this is infrequent and we decided the effort to implement and test a fix as described was outweighed by the simple solution of requiring a reboot: a process Windows users have come to expect with installing software anyway.