Video Screencast Help

Altiris 6.9 WinPE Problem - Unable to connect with Dagent for status updates

Created: 30 Sep 2013 | 2 comments

Hi there,

I have a strange problem that only appears to happen on one computer.

When I boot into Windows PE over PXE it tries to map the eXpress share, but it fails.

A different share is mapped without problems.

The DAgent Status shows the following message:


I installed computers already with that type of Hardware without problems. Also a different computer at the same network cable / switchport worked without problems.

Is there anything I can check under WinPE or on the Deployment Server itself?

Thanks a lot!

Operating Systems:

Comments 2 CommentsJump to latest comment

BBC's picture

I have seen this on various occasions and most likely it is a licensing issue on the DS console. I usually do as a workaround the following:

1. Stop the Deployment Server services (PXE is not relevant to this);

2. Run the licensing utility against the Express.exe;

3. Start the Deployment Server services again.

Also check all computers on the DS console if they run a trial license or have an expired license. I found that in case you have 2+ clients in such a state, you will see such behavior.


PS: Without knowing what version you run, I assume it is SP4 or higher ?

Maymne's picture

Another issue that can cause this is having too many hardware devices that auto-mount. Since the default letter for the server mount is F, that means that it only takes 3 additional devices or drives for the network mapping to fail (C for hard drive, D for optical, and then E and F as either additional hard drive partitions or a 4 in one reader or anything similar), and it's not very clear when you're in that situation why it's failing. The easiest fix is to just change your mapping letter. Our organization always changes that to Q, as it's unused and fairly high up. Just remember to remove the mapping information from F, as if you leave it in, the mapping WILL eventually succeed... but your PXE may or may not work, irregularly.

The hack around the issue that we did when we first ran into this was deploying the FAT32.IMG blank hard drive image using DOS or Linux. Since DOS doesn't mount the additional drives and it doesn't support NTFS natively, it's less likely to fail due to drive mounting. Since Linux doesn't have the drive limitation as it uses /mnt points, it completely sidesteps the issue.

But for a more robust avoidance of the issue, I highly suggest changing your network share letter from F to something like Q.