Video Screencast Help

7.5 - DeployAnywhere issues - DS upgrade is a mess for me

Created: 07 Jan 2014 | 51 comments

I have to rebuild all of my images to get the latest agent (otherwise imaging failes on reboot to production and/or agent is trying to upgrade while tasks are trying to run).  Luckily (or so I thought) 90% of our computers share 1 hardware independent image, so I upgraded agents on that image and when bringing it down various drivers are missing on various machines - which was NOT an issue prior to my upgrade.  I see the driver DB was moved.  Is it possible I lost driver files in the move?  Of course I didn't back up the DriverDB folder prior to upgrade and shadow copy doesn't go back far enough at this point. 

When restoring the HI image, on one model wireless drivers were missing.  On another model, it's display drivers.  Can't wait to pull out every model we own to play the what's missing game & hope I can get some working version into DriverDB!

Also, to get USB3.0 drivers to work with DA, Symantec posted this tech article - http://www.symantec.com/business/support//index?page=content&pmv=print&impressions=&viewlocale=&id=TECH205253 which worked fine in 7.1.  It looks like the path to dpinst changed that there's a 1 now in the path.  That's the problem with one off fixes like this - they tend to break with upgrades and the customer has to track down tech articles that don't seem to be updated when something breaks.  

I'm so frustrated with this upgrade as far as DS is concerned.  Before even finding this DA issue, I've already overcome 

1) PXE didn't work initially.  I had some of the old _netboot related services still running.  I stopped them and at some point now they don't show in services.msc so I assume the upgrade was supposed to stop/remove those old services.  I rebuilt preboot configs, etc until I finally was able to PXE boot new and existing computers without using the console.  This took way too much tinkering customers shouldn't have to do.

2) No images being able to be deployed because they weren't moved properly as part of the upgrade.  I moved disk image files myself and renamed paths in console to overcome this, thankfully someone on Connect pointed me in the right direction before I could even get to talk to someone with support who knew what they were talking about.  This is after L1 support told me completely wrong info (install package services on NS), which luckily people here told me not to do.

3) One image just missing.  Luckily I had a backup to restore from.

4) Disk images I was able to move and repoint in the GUI, but apparently if you use backup images and they don't move like they should, you'll need to do some DB work to make those work again.  

5) Rebuild all images to get latest agents.  This will take me a week or so.  Is there no way Symantec could do some upgrade of deployment agent files to not break the imaging process?

I thought waiting for HF2 was long enough to wait to attempt this upgrade, but apparently not.  

 

Operating Systems:

Comments 51 CommentsJump to latest comment

Sally5432's picture

Just FYI for anyone thinking of upgrading, post image every model Dell we use hardware independent imaging with Deploy Anywhere was missing at least one driver.

I was able to get 2 models working reloading missing wireless drivers into DriverDB.

These other 4 I'm still struggling with - and they were working prior to upgrade - all win7 32 bit.

1) Dell optiplex 780 audio not working - This was previously an issue for me, and resolved by support for me back in 2011 with Etrack 2357884 - my old post here https://www-secure.symantec.com/connect/forums/importing-driver-problem-broadcom-ush-soundmax-hi-def

2) Dell Latitude 6220 graphics driver not working   

3) Dell Latitude e5430 - USB 3.0 not working even with modified DPInst script running post image as directed by http://www.symantec.com/business/support//index?page=content&pmv=print&impressions=&viewlocale=&id=TECH205253  - also on this model video drivers not working.

4) Dell Latitude 6230 - USB 3.0 not working even with modified DPInst script running post image as directed by http://www.symantec.com/business/support//index?page=content&pmv=print&impressions=&viewlocale=&id=TECH205253  - also on this model video drivers not working.  

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

BugTastic's picture

Upgrade sounds like a nightmare. Think I'll wait for V9.5 HF 27 rollup 94 patch 34 MR 87 to come out before attempting any! :-)

 

Sally5432's picture

Just posting here as FYI for anyone thinking of upgrading who might have same Dell models 

Besides the Dell desktop Optiplex sound issue, here are the 3 dell laptop drivers I'm still struggling with

6220, 5430 and our 6230 share a graphics driver - Intel_Corporation.igfx.9.17.10.3040.  When these models restore, it's using 'integrated vga,' if I right click in device manager and select update driver and point it to this folder on NS, it works fine so the driver in DriverDB is fine.

5430 and 6230 are missing a bluetooth driver.  If I right click in device manager and select update driver and point it to the DriverDB folder on NS, it finds driver and works.  So, again, the driver in DriverDB is fine.

5430 and 6230 are missing USB3 Host file.  This is after I run modified version of fix here (DPInst is now located C:\Drivers\Symantec\NonCritical1\run_dpinst1.bat)  https://www.symantec.com/business/support/index?page=content&pmv=print&impressions=&viewlocale=&id=TECH205253 If I right click in device manager and select update driver and point it to the DriverDB folder on NS, it finds driver and works.  So, again, the driver in DriverDB is fine.

These 4 dell models all worked fine with DA prior to 7.5 upgrade.

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

SK's picture

If you are using site servers with the DS TaskHandler, then they have most likely not been updated with the latest driverdb, as you have confirmed that the SMP's driverdb is OK.

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads.

Sally5432's picture

No site servers here, small environment, everything (except sql) lives on NS, but thanks for trying to help

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

jpellet2's picture

I know DeployAnywhere is a nice tool and very handy but it doesn't always work. Have you tried a script task to simply identify the model type and then manually install the driver later on in the imaging process after it has gone through mini-setup? We have to do this with the E65xx series video drivers and a few others.

Sally5432's picture

thanks @jpellet2 I know that's an option.

DeployAnywhere did work 100% for me, at least after I labored with support on it back in 2011.  The same models just stopped working with the 7.5 upgrade.

I'm not ready yet to give Symantec a 'bye' on this and script around the issue.  I think/hope working with them makes the product overall better for everyone.

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

Sally5432's picture

Just an update that unfortunately there is no update.  Few weeks post upgrade and no update from engineering on DA issues :(

 

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

Sally5432's picture

Still no DA fix after a month now.  To make it worse, new model dell 7240 reports a ton of missing drivers (including critical NIC/wifi so imaging fails).  For anything 'missing' in device manager, if I manually say to update drivers and point it to my NS driver sharepoint, windows finds missing drivers and machine works fine.

 

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

Sally5432's picture

Feb 18th and still nothing back from development.  If you rely on deploy anywhere - don't upgrade to 7.5.  

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

jlawson's picture

Sally5432 I'm also battling Deployment now with 7.5.  I have been down for 21 days now with no end insight.  PXE is jacked up and will not boot a PC and we use only PXE.

Sally5432's picture

jlawson - I had trouble initially too with PXE.  I forget exactly what fixed it.  When I looked on the server the old 4 PXE services were running.  I stopped them manually and then at some point they disappeared and was left with the new PXE 7.5 service.  I also recreated boot images (in case you hadn't tried that yet).  Are you HF3?

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

Lark's picture

Sally5432 - I had exactly the same issue with USB3 and Dells (well actually it was a desktop but same result) in DS 7.5.

USB3 drivers are annoying - they seem to need two pnp detection rounds to work because the real USB ports are not visible to the OS until the root hub driver is installed.  It seem that the manual gui method of adding drivers automatically triggers the second round and installs the second set of drivers.  What-ever deployanywhere is doing it does not.  I can speculate that this is related to driver search paths but I'm not sure.

No matter how I triggered the C:\Drivers\Symantec\NonCritical1\run_dpinst1.bat script I couldn't get it working.

As I was consulting into a client and just couldn't spend days and days on this with support I added a Quick Delivery Task to the build job with a cmd file using the pnputil command.  That worked like a charm.

I appreciate you're after a working solution using deployanywhere but I thought I'd just let you know what worked for me.

For anyone else reading DS 7.5 does work - you just need a little patience.  And the latest hotfix!

Sally5432's picture

My issue isn't isolated to USB3.  That just happens to be one of the drivers not working.  I also was running a .bat script prior to 7.5 to get USB3 working.  See my comment in my thread from May 2013 here where Symantec suggests doing just that

https://www-secure.symantec.com/connect/forums/dep...

Are you using Deploy Anywhere with various drivers successfully?  I'm running HF3.  It didn't fix anything related to DA.

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

Lark's picture

Yes most other drivers were fine.  I think that particular environment was actually HF1 with a couple of newer files provided by Symantec Support to address an issue with the WinPE build package.

From memory that particular model had an AMD video card that needed a quick delivery task based install but thats not a new problem.

SK's picture

I wonder if DS 6.9 SPx has the same problem?

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads.

Lark's picture

Thats a good point about 6.9 SPx.  I've not compared the deployanywhere files between 6.9 SP6 and 7.5 HF3.  I wonder if they can be interchanged if one is newer (and presumably better)?

JannasTo's picture

I've also hit a problem with a model that worked in previous version of DA OK which now doesn't. It seems to install the driver but must be missing something as it wont connect to the network. IF I do a manual install of the driver after this it works OK. I have tried importing into the DB again with no success.

jlawson's picture

I will say some of my issues have been resolved by installing HF4 which was released yesterday.  PXE is now working and now working on my DS task working inside PE. 

Specifically I have noticed a difference in Driver management fyi working better in HF4.

JannasTo's picture

Do you have a link to info on this please ?

Thanks

jlawson's picture

I do not it was the first thing Advanced DS support did yesterday when working with me.  I can only say things have been more positive since installing HF4.  Upgrade SIM but HF4 upgrades the Platform, Software Management and DS.  Support said upgrade it all do not only do part of the install.

Sally5432's picture

Here's info.  It does mention some DA improvements but i'm told unlikely to fix my issue.  I'm going to give it a few days released before I go ahead and install b/c with my luck something else will break.

https://www-secure.symantec.com/connect/blogs/itms...

 

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

jlawson's picture

Well I was down and out so really it could not have got any worse.  Just wanted to mention that it really has been working better and I noticed DA working much better but...  FYI my preboot drivers got wiped from HF3 to HF4.  Only my preboot but they did get wiped.  I only had one driver in there anyways so no big for me.

Sally5432's picture

thanks for heads up on preboot drivers.  will make sure to create backup copy of those.

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

jlawson's picture

Sally fyi,

HF4 and I'm sure HF3 also is totally messed up when trying to get OS drivers into the system.  I basically am at a point right now working with advanced support where I have a nic driver loaded like 5 times in DA but it still does not find it.  It is marking the OS as not valid even though it is.

The other issue I'm getting is it wants Hard Drive drivers.  There is no HD drivers.  So since upgrading to 7.5 on 2/4 I have been unable to deploy anything.

Sally5432's picture

jlawson - in your deploy job.. under deploy image options, try selecting 'bypass driver validation' and select all.

This solves a lot of my problems (except VGA and USB issues)

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

JannasTo's picture

I also had to create a script job just after the deploy image task to copy Drivers to \Windows\inf directory - this resolved one of my issues where the NIC wasn't getting detected.

 

Sally5432's picture

@JannasTo - is it showing properly installed in device manager?  try doing update driver and point it to C:\program files\symantec\deployment\driversDB.  This is a new folder DA creates.  Support is still working with me to figure out what's broken but if device manage is missing NIC device and this works, this at least proves driverdb has the right files and should be able to install them.

This trick doesnt work for all of my missing drivers, but it does if missing critical NIC drivers.

 

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

JannasTo's picture

Yep - its showing fine in device manager. I think I will log a ticket for this.

Sally5432's picture

No real solutions for me now 9ish weeks later or an ETA of fix coming. Turning off driver validation helps but doesn't help with USB3 or display adapters.

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

ortolani's picture

I know this is a complete different approach, but in our environment we decide not to use the DeployAnywhere to inject the Drivers, due to the fact that sometimes when injecting a newer driver into older model cause problems and with the DeployAnywhere we can’t really specify which driver to deploy. So to fix this solution, we build our own structure where we have a list of all the current models and each one has its own drivers.

 

List of models we current support in our environment:
drivers.jpg

 

The folder structure looks like this

Deployment (this is the folder that we shared)

  • Drivers
    • Win7x64
      • All the Computer models show on the picture above
      • inside each folder we have: audio, chipset, nic, video, usb3 and so on.
  • Scripts (this is where I move DISM.exe x86 version, to inject the drivers)
  • Sysprep (this is where we put our unattend.xml)
    • Results (everything we deploy the unattend.xml get insert on this folder, so we can check if there was a problem with the xml)

 

I’ll attached the script we use in our environment, where this will:

  • Retrieve
    • Serial Number
    • Machine Model (this is use so we know which driver folder to used it)
    • MAC
  • Map to the Altiris Server (this case the package server)
  • Modified the XML (in our environment we have a specific name scheme for our computers)
  • Inject the XML to the image
  • Inject the Drivers into the image

 

Also I attached our version of the “unattend.xml”

  • Line 27 - <ComputerName>%SERIALNUM%</ComputerName>
  • Is where the script modified the name of the computer to be anything you want, remember there is a character limit, and I think is 15 characters.
AttachmentSize
DeployScript.zip 5.63 KB
resendesw's picture

We have done something similar.  We run a script that scans within WinPE for PNP devices and matches that against a list of hardware based on Model. If a match is found it copies that driver folder from the network to the workstation.  Once Windows setup starts it uses this directory to find drivers to install.  After the fact we run a similar process (for those hardware devices that PNP couldn't detect in WinPE).  Detects Model and OS Arch (x86, x64) and compares it to a list.  Matches are copied from the network to the workstation and the driver setup is run silently.  We also have a section that checks for hardware PNP could not detect and for aftermarket items (such as Video Cards).

We have found it works so much better then Deploy Anywhere (at least in the 7.1 series)

Sally5432's picture

orolani - appreciate the detailed write up.  I am documenting it for future use in case of emergency.  I still want Symantec to make the product work like it is designed to.  I'm told the VGA fix should be coming sooner rather than later.  

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

Lark's picture

I agree with you Sally5432 - This is basic stuff that DS SHOULD do very well out of box.  It seems reasonable to expect any driver that Windows plug-n-play driver detect should work with DeployAnywhere.  This is currently not the case.

Do you have an open support case?  Have you had any indication of when it will be fixed?

Sally5432's picture

Yes I have a case and am waiting on ETA.  Support has been working with me on it.  It's most surprising I waited 2.5 months post release to upgrade (on purpose) and these issues were new info to support.  In fact, in 7.5 the process of which DA deploys drivers seems to have changed significantly which support was also working through for the first time with me.

Unfortunate for me, makes me think I'm one of the few who doesn't script around DA, or at least one that upgrades semi regularly.  

 

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

JannasTo's picture

It must just be us 2 then :-) . I dont use scripting either but fortunately we use Lenovo who have a good tool for deploying drivers once the image is deployed.

 

jlawson's picture

Sally,

I agree 100% and I also waited as long as I could until I required WinPE 4.  I'm also workign with support regarding my issues.

The strangest part to my issue and what makes me think scripting driver injection will not help is...  I have imported all the drivers into my install.wim file and fully tested this on a usb stick deploying win7.  If I use the same install.wim file in DS over pxe I get critical boot drivers are missing when trying to deploy using DA or even turning off DA.  I do believe they mentioned they have seen this issue with one other customer.

The one scripting method that could possibly work has been mentioned before is to not use DS deployment task at all and script the install command myself into a scripted task, removing DS from teh equation entirely.

Should it be this way absolutely not.  Do I have to deal with it? yes.  For now it is usb deployments until we get this handled.

ortolani's picture

I agree with Sally I wish all these tools were incorporated into the DS and just works. But until that time comes we decide to push forward and make the best of what DS has to offer. With custom code and customizations we turn DS into a very useful tool, but we still don’t use DA :(.

With the introduction of WinPE 4, we incorporate PowerShell and .net tools into the WinPE environment, current our DS does:

  • Push image
  • Inject drivers into the image base on models using DISM, this is call by a script task.
  • Update BIOS
  • Update BIOS Settings, like: boot order, wol, pxe and also set a password
  • Inject unattend.xml with custom computer name, like we use a letter (define type) – Serial Number, but in reality can be anything
  • Have a code that uses SOAP (since mssql connection is trick in WinPE) that updates the status of a ghost image, so from an internal web page I can check percentage of an image
  • Also code a tool that does the same thing as the Initial Deployment Menu, but the difference is that my interface allow a user to launch anytime while in WinPE and require authentication. So only authorize users can run it.

If you are interest in learn more I don’t mind send the info I have. Also I just post an article explain the process to customize WinPE 4 in 7.5 with different type of tools case you are interest: https://www-secure.symantec.com/connect/articles/how-modified-winpe-4x-altiris-75, just remember that customizing WinPE is not support by Symantec.

Sally5432's picture

Updating Bios and setting bios settings is slick... as is requiring users to authorize.  Consider me jealous.  

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

Mikhail Brunes's picture

Recently had an issue with the correct drivers being in the DDB but not being applied to machine correctly. What we did was check device manager of the machine with the missing drivers, go to device without drivers open properties, then go to details. Find the Hardware id (i.e. PCI\VEN_10DE&DEV_0DFA&SUBSYS_21D117AA&REV_A1\4&F1563AD&0&0008} ) then on the NS do a seach on the entire DDB for part of (or all of) the hardward id this should show you the .inf files that suit your device. Double check that the file in question should be for your device (i did a google search on the file name that the hardware id was in to verify). Open up the .inf and look at the [control flags] and ExcludedFromSelect = 
Now make sure it isn't set to all (*) or has your device listed by its hardware id. If it is you need to comment out the values in the ExcludedFromSelect.

Make sure you have bypass driver validation set to all in your deploy image job settings because this will not be a validated driver now.

 

Anyway that is what worked for us.

 

ITS TAPP Support

More details: info@itsdelivers.com

Thomas Baird's picture

One last post here as a "symantec employee" before my status is updated.  I've actually left for a consulting firm and my profile will be updated accordingly.

We've been so busy working on these issues I've not been out here to participate, but Sally and JLawson both know me well by now.  :D

That said, we do know what happened to cause these issues and are actively working on a fix - well, Symantec is actively working on a fix.

For starters, if you go to the Recommended Reading List, you'll see a link there about Driver Injection.  It's no longer just DA, and that is the root of Sally's problem.

For JLawson's problem, the trick was that DA runs even if not selected in the Scripted OS Install job, and this time, it WAS DA that changed - that is, it looked at Hard Disks as a critical device instead of non-critical and thus would stop the install process even though the WIM had the drivers.

Soooo, the process is changing.  Look for fixes in HF5 of course, and possibly point-fixes.

IF you are striving to use DA and seeing these or simlilar problems, let Support know.

OR

Or you can script around it of course.

 

 

I should take the time to point out one weakness of scripting that, frankly, most here wont care about, but that DOES affect some Symantec customers.

ALL of the scripts I've looked at in the past uses UNC drive mapping to accomplish their goals.  I do have customers that literally block all UNC mapping because it's a security risk.  Symantec, being a security company, has a responsibility to find ways to accomplish goals without drive mappings.  They've done this in this product by enabling HTTP/HTTPS communication for packaging and downloading packages.

Brilliant, but limited when it comes to imaging and driver installation.

It's the change to support driver downloads over HTTPS that has caused the issue you're seeing, because DA is designed to work over UNC.

Soooooooo

DS 6.9 has not been changed to use HTTPS and therefore yes, DA works just the same there as it always has and will NOT see these issues.

 

I hope that clears things up a bit.  Yes, the problems still exist, though Sally and JLawson will be getting fixes as quickly as they can off the press.  And yes, Symantec will make driver injection work as designed, and yes, people will continue to script around it.  But at least you know the facts.

 

Sorry about my delay at getting out here.  :D  I'll strive to do better in the future!

Thomas Baird
Looking for opportunities
(translation: unemployed!  LOL)
Yes, able to help people beyond the forum if need be.

 

SK's picture

Quote: "One last post here as a "symantec employee" before my status is updated. I've actually left for a consulting firm and my profile will be updated accordingly."

Symantec is losing yet another valuable resource!

Will they ever reclaim the knowledge lost? Only time will tell I suppose.

All I can say Thomas is that their loss is your new employers gain.

Best of luck, Scott.

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads.

Thomas Baird's picture

Ah shucks!  Thanks!

But as you noticed, I'm not gone from here, just gone from there.  :D

Thomas Baird
Looking for opportunities
(translation: unemployed!  LOL)
Yes, able to help people beyond the forum if need be.

 

SK's picture

Likewise.

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads.

Sally5432's picture

Just to update the thread, the DS team provided me with a DLL which I believe is part of HF5 which fixed most of my issues with DA (HF5 apparently is available now, but I didn't read release notes to confirm).  The new DLL required me to create a new preboot environment (the recreate for whatever reason never captured the new dll).

There are some caveats though.  After using the new DLL, I saw random but often freezing on all model laptops after sleep. The new switch used by DA is applying drivers that weren't applied before so I had to, through a very slow and painful process of elimination, figure out which was the bad driver that DA was now applying (o2 micro in my case in case anyone else sees this exact issue).

Once I removed all O2 micro drivers from driverDB, freezing stopped on all but one model laptop which has yet another 'bad' driver, which I'm still tracking down but appears to maybe be smartcard related.

Even with the new DLL, USB3 drivers still aren't applied successfully, like they were with 7.1 at least where you could run DPInst as post image task to install drivers.  For now, technicians need to manually install USB3 drivers.

I am very thankful to Thomas and the other senior engineers who have worked for hours on end with me to get me to this point.

I am not sure I'll go through another upgrade with Symantec.  This was one sucked so many hours from me over the course of 3 months, and managing PCs is a small part of my job.  While Symantec has great senior engineers who want to help, they are stretched way too thin and working with developers who are across the globe is probably also part of the problem.  

I manage 15x as many Macs (with another mgmt product) than I do PCs with Symantec.  We've had some big bugs/issues with the Mac product too, but I've never spent so much of my own time troubleshooting or had large issues drag on for months.  Once senior engineers are involved with Mac issues and bugs are found, they have client systems on site to do testing with and developers are in the next room or building to work on the issues (and often on calls with customers if the issue warrants it).  I'd love to switch to a similarly supported PC management platform, if one even exists.  

For what it's worth, the Mac mgmt product is also web based, and it only works great in some browsers, but there is no reliability on java/silverlight, etc.  Even better, when I update the Mac Mgmt platform, I don't need to update clients, the binary auto updates and imaging doesn't break.  There's no rush to update agents built into images. I'm not a Mac person, but in terms of management, it's really night and day in terms of customer experience all around.

To be fair, the Mac mgmt company is hiring engineers by the dozens constantly, if only Symantec was too that would restore some faith that there is maybe some light at the end of the tunnel..  

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

JannasTo's picture

I have to agree Sally. This application takes up way too much time on the troubleshooting side.It just seems to be constant.

jlawson's picture

I agree with everything you said here but the MAC parts because we do not use or support them.

I have yet to be contacted regarding my DS case since Thomas has left.  I have converted for now to deploying my SOI using USB sticks and then running my DS Task in a new job minus the SOI Task on the machines.  Works great since I put all the drivers into the install.wim file on the source.  I think maybe they know this or something and have decided to ignore my multiple cases.

On a another note I have posted elsewhere that I was told by advanced line (not DS) to hold off on HF5 until Friday as there is a issue being resolved in it and they will be updating the code by then.  Fun Fun!  You trade one issue for another in every HF it is just how it goes with SMP.

Don't get me wrong I love Altiris.  I loved the DS 6 product the most but 7 series has not been so bad.  Could they do better?  Oh yes.  I'm trying to enjoy the roller coaster while I can since we are being forced into SCCM 2012 shortely.

Sally5432's picture

Update: after almost 6 months after upgrading, still no supported way with the product to install USB3 drivers that I know of.

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

totalyscrewedup@gmail.com's picture

The issue is not just USB 3.0 drivers but many others that require to be installed as 3rd party application (Hardware based applications).

I have solved this problem by doing following:

  1. Created a filter for all devices that have WORKGROUP as domain
  2. Created a policy that uses above filter under "Applied to" with a schedule that runs every 30 minutes for 24 hours (this is up to you how you set it up since you can just leave the "allow the user to execute" checkmark and run the "update" "send" from the device in question)
  3. Built software Releases for each driver that doesn't work with DP with dependencies

Hope this helps someone!

Sally5432's picture

I had all USB3 and .exe released drivers working prior to 7.5.  I don't want the crud that comes along with hardware based apps, so we've always were able to get by just uploading the actual missing driver versus the installer.

We only support a limited number of Dell models though, so maybe it varies with manufacturer.  Dell makes a .cab file available with drivers for each model that has proven very helpful.

http://en.community.dell.com/techcenter/enterprise...

Since 7.5 broke USB3 retargeting, I have techs manually load the driver since we don't reimage PCs that often.  That won't work with our next major rollout though next summer.

If Symantec wants customers to build software releases for each driver, they should say so and support that method of deployment, create Connect How Tos with examples, etc.

---
Don't forget to mark posts as helpful if they are, and mark answers as solutions.

Thomas Baird's picture

Ah guys!  I miss you!  :(

And I've not yet played with 7.5 SP1 (check my profile for an explanation) so I don't know what's worse or better.  :(

 

Totally - not a bad method all things considered, though there are others.  Sally's point remains valid - no "supported" method for those drivers that require a double run of DPInst or for those that have actual installers.

 

And now that I'm not a part of Symantec, well, nothing holding me back from stating that there are lots of valid work-around methods for drivers.

But that still doesn't resolve the issue that for advanced driver management, the product is limited.  :(  I keep pondering writing something just for this segment of the market.  I know it can be done.  I've listened to SOOOO many work-arounds over the years.  One of the coolest was the guy (or gal - I forgeet now) who used MDT to sort out the drivers, then one of those VBS methods to install them based on platform, but that still leaves some holes for the advanced video drivers, right?

Still, if you can get network intact with DA, then skip the rest and let your app do it all AFTER the system boots...  Another thought was what some have done to actually install the agent AFTER and then use SWD in long chains to get anything post imaging done...  <sigh>  Maybe here in a few days I'll work on that.  We'll see how busy interviewing gets or whatever.

 

So sorry to hear that's still an issue, though not terribly surprised.

Thomas Baird
Looking for opportunities
(translation: unemployed!  LOL)
Yes, able to help people beyond the forum if need be.