We are having the same issues.  Anyone have a response? 

We are having the same problems as well.  I had to create a wise script to enable the autologin of the account we use to deploy software to get it to work the same way as it did in XP.  I have only recently noticed your problem 1 and it is with system that are XP SP3.  I don't know why these 3 computers are at the bottom of my list, so I would be curious if anyone knows what is going on.

Solutions and further information:

1) DS ordering issues have been confirmed by Symantec. Apparently a few types of computers, like the HP Evo dc7900 desktops, report into the system as "Thin Clients" with a node type of "3" instead of the standard desktop type "4". This is causing the ordering issue. Symantec have provided me a testing "axengine.exe" version 6.9.436. I have installed this and reset my client conenctions and it has resolved all my issues. Symantec will be bundling this, with a bunch more fixes, into a new SP4 release soon.

2) Screen artifacts in Dagent (and Aclient) have been confirmed by Symantec. They are working on a solution. I have heard nothing back as of yet.

3) Dagent "can" become unstable, although I am still unsure why. It appears to be a combination of things, but certinly a few things stand out;

• Video drivers. Oddly we had Dagent crashing one nVidia driver for a system type we have. After a few crashes, something goes wrong with remote control and usually you find the service has stopped.
   
•  Application using layers, LSP, etc. Anti-virus and Remote Admin tools can isntall these... and we've seen far less crashes now that we've removed some of the applications and installed the new AV patch for "Windows 7" systems.
   
• UAC. It appears that if you get the screen locked out by an in-focus elevated app, and still try to remote control, you could be asking for trouble. Remote controlling systems with UAC still on appears to cause a bit of instability in the Agent.
   
• Software deployments. Like UAC, if you're installing software through the DS, particularly if it needs elevation, you may find DAgent becomes a little unstable.

Since installing a few Symantec test fixes, updating drivers, and tweaking a few things here and there... the crashes have all-but-gone. I am now fairly happy with the stability.

4) UAC/Session issues with remote control (can't remote from the logon etc) have been confirmed by Symantec as known issues and will not be resolved within the "DAgent" life. The new DS uses pcAnywhere as the remote control client, and it apparently does everything we need including logon screen interaction, UAC interaction etc. Apparently those with current maintenance agreements for "Carbon Copy" can request version 12.1 of pcAnyWhere as a stop-gap. There's a KB article on how to integrate it into DS as well. Unfortunately, I am not one of these lucky people and will need to wait for the new DS.

5) Deploying software is now fixed (in testing). Symantec have provided me a texting "default.dll" (for both 32-bit and 64-bit) version 6.9.600. I have installed this on a number of "Windows 7" computers and can now deploy all software that was previously giving me 1603 errors. Symantec will be bundling this, with a bunch more fixes, into a new SP4 release soon.

---

So for me at least... my computers show up correctly in DS, I can deploy images and software, and can *mostly* do the remote controlling I need. Seems I have no excuse now... Windows 7 it is. I just hope Symantec releases the SP4 soon, as I need to have my first production client image ready to roll in four (4) weeks time.

Would you say that?

I thought Sysprep was a required step for creating images. Are you using something else for prep the image? I'm looking for any guide lines for Windows 7 Deployment with DS 6.9 SP3.

Unless your DS usage is extremely limited, you'll hit a number of walls with the current SP3 installation. So, yes, I think SP4 is a must. That being said, If you're only starting out, SP3 and some work-arounds will let you start building a Windows 7 image. With that said, you don't even need SP3! I started to build my "Windows 7" process with SP2. Sure a few labels and descriptions weren't "Windows 7", but the "support" added through SP3 is somewhat limited anyway and everything I had done in SP2 was still good in SP3.

As for the imaging process... here are a few pointers;

a) I've never had much luck using the inbuilt Deployment Server samples and options for "Scripted OS Install" etc. Lucky for me, there is nothing stopping me from using scripts and a little tinkering to achieve the whole image/configure process anyway. More "manual", but a LOT more control. I still use SYSPREP, but my scripts are my own, and seems to work a heck of a lot better.

b) While the supported method for image creation is to use SYSPREP, most people gave SYSPREP the flick and used HII (HAL and Driver injection), unique images (per HAL and/or machine type), etc, and most did that in combination with "NEWSID" to make the computer unique. SYSPREP used to kill alot of things I needed to retain (like user profiles, wireless pre-configurations ettings, browser settings, all "default  profile" settings etc), so I stopped using it in favor of one of the aforementioned processes. As of Vista/7 though, I changed back to "SYSPREP" as the process is much better and far more reliable. It still nukes a lot of things, but it's certainly better than is was. Also, in case you didn't hear, Mark Russinovich from Microsoft (the writer of "newSID") has recently binned "NewSID" and is now claiming that the whole "SID generation" process is no longer needed, and in fact never was. That means, you can always make a model-specific image, then roll that out with some scripts to reset the WSUS and AV-vendor IDs, then you're right... the only requirements are that the cloned computer is removed from the domain PRIOR to capturing the image and will never be used to create a domain (as domain controllers). In both of those cases, bad things happen.

c) I like to keep things "simple" but do it the hard way. I actually used WAIK (WSIM) to generate a whole "unattend.xml" file and am using an external datasource (new database table) with "ReplaceTokens" to produce on-the-fly pre-configured "unattend.xml" files for each imaged computer. An unattend that will name the computer, set admin user passwords, set all language/time/etc options, as well as define a computer-specific OU and add the computer to the domain. It does everything automatic. It also allows me to use the post-ooBE "setupcomplete.cmd" file to install drivers, the DAgent, and other requirements before a logon screen appears.

d) As DS can't really do multicasting with ImageX (thats a MDT/Server 2008 feature), I use an Altiris image of a SYSPREP'd base. For my deployment I boot into WinPE v2.1 automation, use a script to check and configure disk partitions, lay down the Altiris image, then drop the tokenised "unattend.xml" file I generated into the "Panther" folder, then script the BCD so that Windows loads off the new HDD. I let the system reboot and it fully configures my computers for me. With KMS, the systems also become activated. Down side: It would be nice to inject software, patches and drivers into the WIM via DISM and deploy that... rather than the somewhat un-touchable Altiris image format. Up side: Unlike ImageX, I can multicast the disk image to hundreds of computers to speed up the deployment,

e) As for "drivers", I do a model detection within automation and copy across the driver repository and driver-installer script to the system, I then execute the driver installations with the "setupcomplete.cmd" option. This runs without UAC, post OOBE, and pre-Logon. Works a treat.

f) Also, to avoid nasty imaging issues whereby an "Agent Update" interrupts the system, my base images does NOT contain the "Dagent". During automation I also copy down a "installer" script and the Dagent MSI. My script installs the Dagent and injects all the required configuration data the system needs. This is also performed within the "setupcomplete.cmd" file. Reboot and BAM... fully configured computer form a single Altiris source image file.

--------

One parting note: If you're slowly building, testing and re-capturing your images... remember to set the "SkipReArm" option (which can be done within the registry). Without this, you only get three re-arms before your images are toast and need to be rebuilt. If you don't have a KMS yet, I suggest you build you master computer, activate with an MAK via the VAMT, build and ALWAYS set the "SkipReArm" option. Each time you system loses it's activation, you can use the VAMT to re-deploy the MAK to the computer without using another MAK license.

I plan on blogging about my W7 investigate, deployment and tweaking experience... until then, feel free to ask me questions.

Murray

I look forward to a article or blog about how you are doing your Windows 7 deployment.  I have also not had much luck using the Scripted OS installs (SOI).  It has always been easier to use manual scripts instead of the SOI because of complete control allowed with using my own scripts.

As for SP4, didn't they just (with in a few months) release SP3?  I don't suppose they have some hot fixes for some of the things you have fixes for?  The main thing I am looking for is your #5.  Everything else I can deal with until SP4.

SP3 came out a few months back, yes. Unfortunately it broke more stuff than it fixed. Everyone installed it because it had "support for Windows 7", but problems with the agents, remote control, ds engine, etc have made then build and release a number of hotfixes... so many hotfixes now, that a service pack is probably required.

Anyway, looks like Altiris have updated the KB article and added the testing DLL they made for me. Feel free to get it here:

https://kb.altiris.com/article.asp?article=49390&p=1

This will solve your software deployment issues.

EDIT: I just noticed that the DLLs added to that KB are v6.9.437 and the article talks about "Vista" issues and support. The build they sent me was v6.9.600. I am unsure if the "600" was to designate a "testing" file or not. Feel free to try the one attached to the KB... I will be in touch with my Symantec Case Engineer to confirm.

Just found another issue. While Symantec have released a fixed "axengine.exe" for the DS ordering issue... they have only fixed the "dc7900 SFF" systems. We also have the "CMT" and "USDT" versions and they still appear out of order. I was going to post up the replacement AXENGINE details, but it seems that it's not fixed yet.... so I won't.

Even after getting the hotfix I am still encountering the same issue. Im trying to deploy the MSI and it says it complete but it does not install. It does install if I run it in the user console and they are an admin.

@davidhilling: Thats an interesting issue you have there... but I have a suggestion. Can you try looking at the MSI within "ORCA" (or whatever you MSI/MST tool may be). Can you check the "Property" table and ensure a value is there called "ALLUSERS", and that it is set to "1" or "2".If the MSIEXEC process returns a status code "0" and the deployment gets a green tick, then it sounds like the installation worked as expected. What you may be finding is that the application defaults to a "per-user" instalaltion and is only providing the necessary shortcuts, advertising and components to the user account that installs it. In this case, you may find that the "SYSTEM" account, or the runas user specified int he DS job, will get the instalaltion, but no-one else will. Setting the property above will convert it into a per-machine instalaltion, and could either resolve the issue, or at least assist with further diagnosis.

Another cause, of course, could be that the installation requires a UILevel greater than you are permitting in order to trigger custom actions. If the instalaltion is dependant on custom actions, and these are NOT in the correct "InstallExecuteSequence" table areas, then thectual install events may not be triggered. I've seen a few applications that trigger a required part of the instalaltion on the press of a "Next" button (dialog) only. As such, a silent deployment would succeed, but the instalaltion was not there. You can test this by setting the "ALLUSERS" proerty above, then doing a series of tests using full, basic (/qb), and no interface (/qn)... then see if the application works as expected.

So my troubles continue. I've also being logging new support cases until my fingers bleed. The result... a LOT more Altiris KB articles and a lot more hotfixes. Here's what we know; Just about all my initial issues have now had hotfixes created and attached to KB articles. Feel free to search the KB for your issues and get the latest updates. Here's my issue though... I needed several hotfixes applied to correct all my issues, and as SOON as I applied them all, I started to experience strange issues with my server. Remote Control became unstable, perfectly running scriopts would return an error code "1" and list as fail even if they succeeded, and well, generally, everything started to fall apart.

I have now reverted back to v6.9.430 components on almost ALL fronts except for the new "default.dll" for DAgent... no issues with that so far. It's also critical that we be able to deploy software to Windows 7, so it needs to stay.

Some new issues I found (which have now been created as KB articles) include;

a) The requirements for something other than "Serial number" in the "Primary Key" is back. The KB article has been changed to remove the "fixed in SP1" line and now lists SP2 and SP3 as having the fault. If you set the "Primary key(s)" to something that doesn't also include "MAC Address", then WinPE automation will start producing 0xC000001 (BCD) errors on boot. This was meant to be fixed and allow users to run with "Serial number" only, but nope... still required.

b) The new Dagent does bad things to user profiles. For some reason it locks the "CryptnetUrlCache" folder on logoff. This may not be an issue for most, but in a multi-user environment where everyone uses roaming and/or mandatory user profiles, this results in a 0 byte folder for the user profile remaining on the hard disk. Subsequent logons will then change from "name" to "name.domain" to "name.001", then "name.002" and so on. Eventually seeing hundreds of user folders in the "C:\Users" location. If you stop the "Altiris Deployment Agent" service prior to logging off, then the profile is released and/or deleted correctly. It's now a "know issue" with no known fix at present.

Thanks for the excellent posts NKX.  I've experienced several of the issues you've mentioned and am also looking at deploying Windows 7 soon.  DAgent overall is very disappointing right now.  I have to admit that I'm quite frustrated with DS at this point, and wonder if Symantec will destroy a once great product.

I spend more time troubleshooting than administrating, and that is not acceptable long-term. 

But for now, is there any word on the SP4 release?