Category: Deployment

When you are about to run MAP (Microsoft Assessment and Planning Toolkit) assessment it comes by default with a SQL Server 2008 R2 Express database. This has a limit of a database of 10GB. This is in many cases not a problem but in larger environments it can be.

My experience tells me that a 10GB database is good for keeping data for about up to 10 000 machines. If you hit the limit the best option is to use a fully licensed SQL Server which has no limits on the database size.

The second option is to divide the scans to say for instance different OUs and switch between multiple databases. This does not give a combined report in any way so it is definitely not the best option but it will get you there.

The latest version of MAP 6.5 can be downloaded from Microsoft Download Center.

When companies deploy Windows 7 most of them are looking at the 64-bit version of Windows 7. This architecture of Windows does not support running 16-bit applications, which unfortunately still is widely in use. If you do an inventory with ACT (Application Compatibility Toolkit) it will inventory all executables as well as CMD files and some other stuff and it will contain information about 16-bit applications lying around and being used by the users in your business.

The trick is that the GUI does not provide a way to view these applications so you have to turn to doing a SQL query using for instance the SQL Management Studio Express tools. Use the SQL Query below to get information on any none 32- or 64-bit executable. The query (thanks to Chris Jackson) will return for instance WOW (Windows on Windows) or DOS applications and that will/might indicate a 16-bit app which you should prioritize to test and handle as necessary.

USE ACTDATABASE
GO

SELECT DISTINCT Applications.appName, Static_App_Properties.fileName, fileModuleType

FROM Static_App_Properties
INNER JOIN Application_Instance_Files
ON Static_App_Properties.identity_hash = Application_Instance_Files.filePropertyID
INNER JOIN Applications
ON Application_Instance_Files.appID = Applications.identity_hash

WHERE fileModuleType<>'32BIT' AND fileModuleType<>'64BIT' AND propertyType='File'

ORDER BY appName
GO

Happy hunting for 16-bit applications! :)

During the deployment roadshow me and Johan did recently a recurring question was if it is possible to set the default boot image in WDS if one have multiple boot images.

Well of course you can set it, just go to Properties for the WDS server and go to the boot tab and choose a default boot image for the architecture you want to set a default image. Note: This sets the default boot image to the one you choose but you will still be able to choose another boot image in the list of boot images.

Right smack in the middle of the deployment roadshow talking about deploying Windows 7. Tomorrow it is time for the fourth city (Linköping) and it will be our pleasure to announce that USMT 4.0 now finally migrates Office 2010 settings, as of a few hours ago. Download and install from http://support.microsoft.com/kb/2023591 and follow the instructions for updating the USMT components if you ar eusing LiteTouch or ZeroTouch deployments.

On November 25 me and some colleagues from Knowledge Factory as well as Specops Software and AddSkills will be hosting a Windows 7 deployment day. Johan Arwirdmark gives a short teaser…

There a number of group policies that can interfere when you are deploying Windows 7 machines, one of them being the “Admin approval mode for the built-in local administrator account” which if set to enabled breaks deployment using the Lite Touch scenario using Microsoft Deployment Toolkit.

My fellow MVP and now also colleague Johan Arwidmark has a blog post on two methods for handling problems related to group policies when dpeloying machines, either by settings filters on your group policies or postponing the domain join process.

The other week I stumbled across a very interesting fact, a fact that the Windows Deployment Server service refused to start on a clean installed Windows Server 2008 R2. After troubleshooting for a whole day, even reinstalling the OS, reproducing the error even without any patches seemed very strange. The WDS service is a service that normally just works. The following error was logged:

Log Name: Application
Source: WDSServer
Date: 2010-10-04 17:14:23
Event ID: 257
Task Category: WDSServer
Level: Error
Keywords: Classic
User: N/A
Computer: wds.contoso.com
Description:
An error occurred while trying to start the Windows Deployment Services server.
Error Information: 0xFFFFFBB3

An important fact is that the server to be used for deployments was a retired yet powerful TS/RDS server with two six core processors using hyper threading, making it 24 logical processors.  Not likely to be the hardware specs of a regular deployment server but hey, it can obviously be scenarios where this might be an issue. Thanks goes to a colleague (Jeanette) who figured out that we could try to set the number of logical processors being used to two. Guess what, after a reboot the WDS service started just fine!

To change the number of used processors we used:

bcdedit /set {current} numproc 2

To revert this change you could use:

bcdedit /deletevalue {current} numproc

After some work with Microsoft Product Services and Support it appears to be a bug nevertheless. The limit for the number of logical processors you can have for the WDS service to start is 20. Bear this in mind…

There is a bug in Windows Deployment Services (WDS) in Windows Server 2008 R2 which prevents your pre-staged computers from booting via PXE. In the Event logs on the WDS server you can find event 519 stating that there are duplicate machines with the same GUID or MAC address, even though this is not true. There is a hotfix for this problem which is available from http://support.microsoft.com/kb/2028840/en-us.

The event looks like:

Log Name: Application
Source: BINLSVC
Date: 2010-09-24 10:29:04
Event ID: 519
Task Category: BINLSVC
Level: Error
Keywords: Classic
User: N/A
Computer: wds1.contoso.local
Description:
Multiple machine accounts with the same GUID or MAC address were found in Active Directory Domain Services. The Windows Deployment Services server will use the first listed machine account.

List of matching machines: CN=DEPLOYTEST1,OU=CONTOSO,DC=stenis,DC=local

I’ve received a question on why Microsoft stopped supporting the old way of making changes to the default user profile in Windows 7. As you might already know the only supported way to make changes to the default user profile is to make them with a local user account and then sysprep the image with an answer file containing CopyProfile=TRUE.

The question or should I say problem is that the user in question find it ineffective to make changes to the default user profile, by installing the image to a machine then make the changes and once again to sysprep and capture the image.

Fortunately there is a much more effective way to make changes (though unsupported). Just mount the image using imagex or dism, and then add or remove the files you want. If you want to change some settings they most likely stored in the registry so then you can just start the regedit.exe utility as usual and then mount the ntuser.dat file within the image to make the changes and when done just applying the changes and you are done!

Deployment Guru Johan Arwidmark wrote a blog post today stating that there is now a hotfix that resolves a rather common problem during deployment, where one after the deployment get to choose the network location although the profile used is the domain profile and the location therefore should be “Work”. The fix has KB article number 2028749.