In order to add Data protection manager as a step in the MDT build process we need to complete 2 steps:
1. Install the DPM agent onto the target machine
2. “attach” the target machine to the DPM server.
Step 1 is easily achieved by calling the agent installer with the DPM server full name as a command switch.
Step 2 is much more difficult as there is no fully support micrsoft method to automate this that I could find. You can manually attach a client to the server from the DPM console or from powershell.
Therefore with a powershell script we can create a remote session to the dpm server and script to attach the client laptop as a step in MDT after the agent has installed.
So far my script looks like:
$credential = new-object system.management.automation.pscredential($username,$password)
enter-pssession -computername DPMSERVER -authentication credssp -credential $credential
attach-productionserver.ps1 DPMSERVER %computername%
It’s still a work in progress..
After updating one of our XP laptops to SP3, a user recieves the above error while trying to use Excel;
“Object library invalid or contains references to object definitions that could not be found”
To fix this, run the following command from an elevated command prompt:
cd C:\Documents and Settings
del /S /A:H /A:-H *.EXD
this deleted several files from the user’s excel temp folder and should resovle the issue
Due to the size of our corporate image, we have to run through the MDT build twice. 1st time to install all the main applications (Which very rarely change), this is then captured and used as the base OS for the 2nd MDT build which is given to our support engineers.
Recently I encountered a problem whereby after I had updated the first build’s service pack level, the 2nd build would then fail with the error:
Windows could not apply unattend settings during pass [offlineServicing]
This is due to the unattend.xml used for the 2nd build having the wrong version number. Check inside DeploymentShare%\Control\%TaskSequence%\Unattend.xml
Within there, Ensure that the version number located within:
assemblyIdentity name="Microsoft-Windows-Foundation-Package" version="6.1.7601.17514" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language=""
matches the same version number as the .exe of the service pack (Obtained by going to Properties – Details
Changing this should resolve the issue
After many years of searching Google for answers to tech problems and reading thousands of tech blog posts for answers I have decided to share some of the solutions I’ve found to the issues I come across in the hope that others will be able to google their error messages and find this with the answers.
If noone does read this, at least it can serve as a record for me to look back on if I should need reminding of a past fix.