Deployment Solution

I have been told recently that i might be better sticking to DS6.9 rather than upgrading to version 7 along with the NS update. I got the impression that this was more down to user preference than functionality/performance issues so i was wondering what other peoples opinions are of this?

I have almost completed the migration of my NS to version 7, my original plan was to upgrade the DS onto the same server once i was happy that everything was working ok.

My existing setup was 'all on one box' (NS, DS and SQL 2005) and my new setup is currently 2 servers 1 for NS and 1 for SQL 2008. I am now worndering if i would be better off leaving the DS and SQL 2005 on the existing server and just un-installing the NS?

Your thoughts...?

Thanks in advance

I'll try to be balanced.  First off, note that there are many readers of this that are pretty upset with DS 7.1.  They have some valid reasons for that.  DS 7.1, frankly, still doesn't have the full functionality of DS 6.9.  We're getting there, but it's not quite there.

For some, this isn't a problem, because they don't need or want the features.  For others, that's a deal-breaker.  Depends on where your needs fit as to whether you should upgrade or not.

My 2 cents: install it in a lab, run through all your known scenarios, and see if it works.

There are some tremendous advantages to 7.1 that people have been begging for over the years, and some customes LOVE it.  You don't hear their comments on here very often, but we get them from vision conferences and such.  Reporting beats DS 6.9 hands-down.  Scalability also does (though it can be tricky today configuring it).  Integration with NS of course if hands-down better.  The automation folders are an improvement.  If you have CMS, yoru ability to do a full deployment with Software Delivery are much better (though a little tricky today due to a bug).

Predefined computers today are harder, but we're fixing that.  Initial deployment is more flexible.  Site Servers are tricky, but flexible.  Image collection is easier though as compared to using the convoluted pxe manager for menus that point to other menus and such to make it scalable.  Bug count is higher (new product) but the engine is more stable.

Soooooo, again, get it into test, and work through it.  Figure out what you need, and IMO, you'll get your best answer that way.  I think today it's about 50/50, but we're tipping the scale, and soon there will be more reasons to go 7.1 than to stay behind.  ITMS 7.1 is a good start that direction so far from what I've seen.

GL!

The DS 7(.1) has been a pain in the ... within my organization.  I start with the biggest pain.  My images will not push down to the PCs!!  The process seemed to work fine then one day, out of nowhere trying to push an image, the PECT agent (the agent used by the deployment server, no longer the DAgent) crashed and to this day still crashes when trying to push an image down.  I use HII imaging for Windows 7 and XP.  I have not been able to iron out the issue.  I am forced to deploy images running my own job script.

Next the DS7 does not pull the same data from a PC when in the build (WinPE?) environment.  This means that you can not tell a PC via the serial number anymore, you have to know the MAC address or IP address/BIOS name given to the PC.  In other words you have to be at the PC you are pushing the image to.  If the PC has been in the build environment before, it will keep the previous name it was given (in DS), even though the PC will report a different name.  Confusing, huh?

If you remove a PC from the DS database, it will remain there for a while (which adds to the heartache of the above).  This is unless you are able to restart the DS server (physically), then the DS will reflect that of the actual Database.

This PC information change can pose an issue for any HII scripting as well.  Before, one was able to tell a PC by the computer model number token.  Now you have to devise a clever way to do it with winmgmt.

The DS is not live, it is web based.  It takes time to refresh, meaning you may not see a fresh PC pop up in the DS console for hours, depending on how you have your resource refresh times set.

It is very hard to add in a license for operating systems outside of pulling the image and its resources into the system with the Altiris Job.

Messing with adding new drivers into you Preboot (WinPE) environment via the Bootwiz or even recreating your Preboot environment is very 'beat-around-the-bush'.

These are the major issues (for me) I have noticed so far.

But some of them need a bit of correction and/or explanation.

1
PectAgent crashes we've been working on.  We know that happens.  MR3 fixed a LOT of them though, so you should be seeing less now.  MR2 and before - yeah - crashed a lot.  If you're still crashing post MR3, we need to know.

2
The PECTAgent does pull the same info from WinPE.  However, the requirements for identifying a computer in NS is different than that for DS.  The developers knew about this but figured they'd better gather the same information that the basic Altiris Agent gathered.  And yes, for predefined computers, this is a pain.  BIG pain.

The good news is that we have a point fix we're testing now that allows you to just use MAC.  I'm not sure if we've gotten to the point of allowing either MAC, or Serial or UUID for identification, but I think we at least reduced it to MAC.  Again, this is only a fix for predefined computers, and it is NOT yet regression tested.  I'll post that out as soon as I have approval.  Keep an eye out.

3
The computer naming issue is simply handled different.  NS "remembers" the name a computer had through imaging.  This allows you to have a system in production called "george" and in WinPE, when it reports up it's name as "MiniNT-xxxx" it wont look like that in the console - it'll still say "George".  However, this is a problem if your system was created as an Initial Deployment system, because then it'll keep the MiniNT name.  Sux.

Personally, I'd like to know more about this specific complaint and how you used it in the past.  Did you really identify your systems in the DS console as serial # or UUID?  Let me know.  I'd like to hear this use-case.  Thanks!!

4
When a computer is deleted from the console, the PXE server service doesn't get updated.  This is a ... bug?  I don't know the official status.  Here's why.  In DS6.9, the PXE server service had a live/open connection to the DB and was kept up-to-date in real-time.  In DS 7.1, to improve scalability, we reduced the real-time connectivity.  However, this exposed a problem.  When a system is deleted in the NS, there's no automatic "trigger" to signal the PXE server service that it's gone.

All you have to do though is restart the 4 services.  Not hard-boot the system.  Here's why.  The PXE server service keeps a list of all "known" systems in RAM.  As soon as you stop the service, RAM is cleared and all "known" systems are forgotten - all of them.  When it restarts, you'll see a "clients.sbs" file dropped on the system with a full list of all known computers.  This is queried in real-time from the DB at the point of starting the service and since the computer was deleted, it wont be returned in the list.

Save yourself some time and restart just those services.  If you have the dependencies set up right, you can just restart the first and all the rest will follow.  Yes, it is an issue.

5
The point on HII scripting is partly true, but not for the reason you think.  More importantly, DeployAnywhere in ITMS 7.1 (currently open beta) will support all drivers.  I've tested this.  What that means is that the need for custom scripting HII is significantly reduced in the next release.  Unfortunately, today, MOST people are relying on WinMgmt to pull the Computer Model.  Yup.  We know that.  Sorry.  There's a better way and we're getting there.  This is definately a shortfall.

6
The console "statuses" is something we've been making a beef over and we're having pretty intense conversations about it.  Not sure what to do.  On the one hand, DS 6.x was really nice for showing real-time statuses, but it only scaled to 2-5K users/server.  Now, in DS 7.x we can scale to 30K users in one console.  Real-time statuses in that environment is completely unrealistic.  Sooo, we have to find a way to 1) have a happy medium, and 2) give users an option.  Neither we've figured out yet.  So for now, he's right - this part is simply missing.

7
Drivers for DA and BootWiz are a pain indeed.

Good news - we now have a web console page for that in the next release.  That's one of the best things we added.  No only do we have a page to add drivers for both, the driver replication is also automated.  This will be in the next release currently referred to as ITMS 7.1 due out march/april.

On this front, I actually created some tools to help as well in the current release.  SMART tools includes some packages for the BootWiz drivers so you don't have to go to each DS Site Server and run BootWiz on each, AND it includes a right-click option for launching the DA and BootWiz tools.  Not as nice as what's coming, but not all bad.

8
The license thing is a bit of a pain.  It's doable, but at some point we'll need to improve that I suspect.  Truth is, it's not as big as the other issues mentioned here, so I've not had that discussion yet.  :P  We'll see.  We have however asked for better support of KMS's.  Don't know where that sits in the plan.  Sorry.

I hope this helps both of you.  That was an EXCELLENT post BTW.  If I sound like I'm ripping on it, I'm not.  Trust me, I'm not.  I'm a BIG advocate internally for improving the product, and I AM listening to all of these posts.  So is the PM.  :D

3

Yes, I did use the PC's serial number in the DS 6.x because it was easily readable on the PC without having to start it up.  We have a list of all PCs that are shipped in by serial number.  We keep track of were they are going and who they will be assigned to for new or upgrade purposes.  We would always know which PC was which because the serial is dependent on the BIOS of the individual PC.

The new way that Altiris does this hinders 'automation'.  Unless the PC is new, you have to know the name given to the PC previously in the system.  You either need to preemptively turn on the system to find out the MAC or be right next to it to ensure the given name to the PC from the Preboot environment.

5

We do not use DeployAnywhere.  We are using the DS with given deploy jobs/custom scripts.  All drivers are injected with scripts.  This is why the 'Computer Model Number' tolken injected into the DS6.x DB is important to us, rather than gathering the info afterwards, from the Preboot environment using the 'winmgmt' queries such as in the 7.x versions of DS.

6

The 30k users ability is definitely a plus, however, the fact that the console must 'refresh' every time you scroll is quite tedious.  Maybe the list can prepopulate more than 20 - 30 entries at a time to scroll through.  100+; depending on time taken to load.  I don't imagine 100 entries would be that intensive?

8

The licensing issue is huge to us.  An image can not be pushed down using an 'Altiris given' job because the OS key must be exist in the resources DB to be applied to the job.  The job will refuse to even be made without it being in there.  The only way to pull in the OS license other than with the 'create image' job (that I know of) is with the resource import tool, which most general users/administrators have no knowledge of unless researched.  The knowledge does not even exist within the 'in console' help files.  We do not use the 'create image' jobs provided by Altiris because the images are pre sysprep[ed] by myself.  We do not include the Altiris Agent on the images as is done by the creation job.  There is at least one key sysprep switch that is not included in the predifed job, and we like to be able to include the 'gui version' of the imaging utility during the job for testing at the PCs.

Thanks for the updates to the other problems though, and I hope the further info can help you.

Excellent information to have.  This is EXACTLY what we look for when making design decisions, so thanks!

No promises of course on pulling it all off.  Every product - every product version even - has it's highs and lows and as such, we adapt.  However, we are looking pretty hard at how to improve the product - it's a real push.  Limitations are, of course, real, but this is a good time to point out what you do.

Thanks again!

Honnestly, we still do not recommend existing 6.9 only DS customers (Deployment Solution), to migrate to DS 7.1, all the same SP1, except for specifics requirements. Why ?

• As long as our DS 6.9 customers will loose the harware+basic software inventory when migrating to 7.1: forgot it ! NO MIGRATION
• Symantec makes already a 1st step, integrating PCanywhere with DS 7.1, to avoid loosing REMOTE CONTROL, thanks for that: next step now please! (I should make a feature request?)

We OK now start using DS 7.1 for new CMS 7.1 customers, instead installing a DS 6.9 as we were doing previously CMS 7.0. I must say they are a lot of new cool things with 7.1, but not sure all will be enough to invest upgrading 6.9 to 7.1, for most our customers using CMS (Client Management Suite, integrating DS).

Not yet :)

I'd like to reply to your 6th point:

'The console "statuses" is something we've been making a beef over and we're having pretty intense conversations about it.  Not sure what to do.  On the one hand, DS 6.x was really nice for showing real-time statuses, but it only scaled to 2-5K users/server.  Now, in DS 7.x we can scale to 30K users in one console.  Real-time statuses in that environment is completely unrealistic.  Sooo, we have to find a way to 1) have a happy medium, and 2) give users an option.  Neither we've figured out yet.  So for now, he's right - this part is simply missing.'

Please, please, please, PLEASE give us the option at least.

We didn't buy the product for 30 thousand machines, we don't have 30 thousand machines, and we never will. Server load is not an issue and we would be more than willing to cop the perfomance impact.

Real time statuses are the number one thing holding us back. If it's not present in the next release we will still stay with 6.9.

Thanks for the post though Thomas, finally someone is giving us some information about future changes.

Would it be possible for someone (say the PM) to post a 'proposed enhancments/modifications' to DS?

Cheers

Rhys

my two cents...

2.  The point fix refered here is already available as a KB (howto?) for 7.0 MR4 and for 7.1 SP1.

3. The computer name is easily addressed by using a token and use the serial number token in the answer file.  

7.  Drivers for WInPE is not that big an issue, it is done the same way as 6.9 :)

Nelo

We include a token for Serial Number in those samples.  There's more than JUST jobs in there.  We added a few reports and 4 new tokens.  We couldn't change everything, but what we could safely do, we did.

The good news is that the PM is very very actively involved in this process, and has probably read the thread.  He's also exceedingly busy.

Real-time console statuses are not on the plate for the next release as far as I'm aware, because we have some bigger fish to fry.  I understand the frustration for our 1000 user environments, but when you loose a sale of 100K users because of some other deficiences, you have to understand that the impact is felt more.  There are some architectural changes we're working on to make sure that DS will not only "scale to 30K users" but do so well.  For instance, customers with 50 locations of 10 users each will find themselves frustrated because of how we tie into your task server for pulling images.  They only need 1-2 Task Servers, but to roll out to that environment, we make them install 50 task servers today.  Not good.

Anyway, I'm not ready to post what is coming because we're figuring out what to keep and what to drop from our wish-list.  We'll see where this takes us, and who knows?  Maybe I'll get the PM to take a peek here.  :D

I understand your standpoint and that obviously your larger customers have more... 'influence' on your decisions and I'm sure they very much appreciate your development and enhancements for them.

Please don't leave the small guys behind though. Just because we have a smaller user base doesn't mean we don't utilise and require all the features that the bigger ones do, including performance. It also doesn't make us less important either. I'm also disappointed that real time updates aren't being considered for the next release too. If you go through 32-bit console thread you will see that quite a few people have requested it.

But again, thanks for following everything up. It's really appreciated. Keep doing what you're doing - and just remeber the little guys who still pay a very large amount to use your products!

I don't know if the latest SP1 for ITMS 7.1 is changing this

(out about 2 weeks before?)

But, I heard from 2 different other partners (each more 10 Altiris specialists), the DS 7.1 is now ok in LAB, with few clients, but not a good idea fro 1'000 or more...

They still recommend also keeping the DS 6.9 for OSD remote multiple sites, in production.

Any body know if the latest SP1 for ITMS (or CMS) 7.1 is changing this, or not ?

First, let me say that I've been using Deployment Server since v5.0. I've tried all of the different attempts to get a web console to work with every version since v5.0. None of them have been good enough to get me to move from my Win32 console. The web consoles that tied in to the Win32 console were the best because they kept the folder structure of the DS, and the display names. They just didn't have a remote control solution, and software deployment wasn't so good because it relied on NS and that meant the agent had to first contact the server for configuration changes. Version 6 introduced the "tickle" of the agent, but I still find the web-based software delivery to be more problematic than the Win32.

DS 7.1 fails miserably at trying to replace DS 6.9. It looks really cool, but it ain't happenin' here for all the reasons listed above, and those listed below. And the list below is by no means complete.

• We prefer to create Groups loosely based upon our Org Chart. Can't do that in DS 7.1. Yes, you can create filters (sux), but that is very time consuming. When we do a Organization-wide software deployment/upgrade, it is based upon department. DS 6.9 gives much better control over the deployment.
• We change the displayed name in DS 6.9 to the user's actual name so the Support Desk can quickly find the computer with the problem. I know. They aren't supposed to be the ones that use it, but NS/SMP just ain't user friendly. You can't change the displayed name in DS 7.1. At least I haven't found a way to do it yet.
• Real time status in the console. I want to know which computers are currently active on the network, and who is logged on.
• Creating a job in DS 7.1 is extremely painful. Software Delivery packages in NS6 is a lot easier. There are a lot of steps to creating a job in DS 7.1 vs. the one or two steps in DS 6.9 (depends on the complexity of the job, of course). I've yet to get one working properly.
• Requesting inventory is near instantaneous in DS 6.9. In DS 7.1, I'm still not sure how to do it, other than wait on the regularly scheduled inventory from Inventory Solution. It certainly isn't available from a right-click like in DS 6.9.
• Reporting sux in DS 7.1. Sorry, but it was much better, and a whole lot easier, in NS 6.x. It wasn't as pretty as SMP 7.1, but at least I could adjust columns. Oh, that may be because of the IE9 incompatability with SMP 7.1 - not a problem wtih NS 6.
• SMP files get scattered all over the server. Alright if you have a server with only one drive (C:), but if your server group wants apps on the D: drive, that's where they expect to see them. Me, too.
• My whole list of suggestions for SMP 7.1, some of which overlap into DS 7.1.

I could go on, but I won't. In general, web apps aren't very well written. When ported over from Win32 apps, a lot of functionality is usually lost. A lot of excuses are usually made for dropping the functionality, or why something doesn't quite work the way it did in a Win32 app, or why it breaks in the web app but not in the Win32 app, or, or, or. But excuses don't help if you need/want that functionality.

You may ask why I stay with Altiris/Symantec. That's because it's still the best product for inventory, software delivery, and asset management. However, if they ever take away my Win32 console, or render it unusable by not keeping it up-to-date with the latest computer technology, that will change.

Also, the DS 7.0 had an ability to add some options before the Preboot kicked in for 'Previously Unknown' computers.  You could choose between the Preboot environment and the 'next boot device'.  This is non-existant in 7.1 that I can tell.  This destroys automation for me.  Unfortunately some important computers lie in the same VLAN as the DHCP for Altiris uses.  Therefor I can not use the Preboot only functionality that is in the current version.  Symantec knew this, as I was working with a high-level engineer on my DS.  At this point  I am forced to vote between no reponse for unknown PCs, OR, everything goes into Preboot environment.  I can not make the important PCs known to the Altiris Server either.

I f I am just not seeing this, or looking in the wrong place,PLEASE, correct me.  I have been all through the DS and PXE configurations.

dsmith1954 - I definetly have to agree about the Inventory/Reporting.  The updating is surely not prefered and everything is below 23 pages of other stuff.  They should be seperated out as before (6.x style).  I am very tired with mucking around trying to get the CMS to work as I need it and DS is killing me.  I will probably have to install the DS 6.x until who-knows and run the 7.1 NS as the Altiris 6.x NS is no longer supported.  By the way, I am still being forced to use the 6.x NS as the live server because 7.x is in a constant state of 'Symantec support'.  Ahhhhhhhhh...

I have been working on a simple task

1. Install 7.1

2. Attempt to build a site server with pxe on another subnet

3. Try to pull and image of a PC and a mac using this product

4. so far, I cannot get the pxe components on the site server

How hard can this be?

BTW, can you clone the new agent?  How do you make a base and sysprep image without cloning an agent?

hmm

What would constitute a previously unknown computer?  As of when does it fall out of that state?  I don't recall that setting.  I think we simply ignored all unknown computers, but I'd have to go resurrect my 7.0 server to verify that, and that thought depresses me, soooooo......

What you're asking for, and what I agree we need, is an option to do MAC filtering.  That's what DS 6.9 had, and frankly, what we're actively working on adding to 7.1 at this time.  The best answer if you have no other way is to ignore all unknown systems.  Alternatively, those computers you don't want to PXE boot you could turn off the PXE options on their NIC's and poof - problem solved.  They wont PXE boot.  :D  I suspect the number of "important" computers you have in this state is limited - that is, it's not workstations accross-the-board, but important servers and such.  Boot into the BIOS and since they should NOT be re-imaging anyway, turn off the PXE boot options.  That way, you'll actually have a faster restart time as well.  Double win.  DS can then respond to unknown comptuers without affecting these.

As for being in a constant state of support for CMS 7.x, I apologize - I don't know how to respond to that.  I hope you have your specific issues up here in Connect as well.

We have several clients using Ds 7.1 SP1a on far more than 1000 systems.  It really depends.  I'm not sure why they'd say it wasn't good for more than 1000 clients.  I'm getting LOTS of positive feedback on large customers.  Granted, we're not seeing it yet for the 50,000 users.  In that realm, due to issues with Hierarchy, we're still limited, but we can easily surpass the 5K limit of DS 6.9.  And we're doing so frequently.

The biggest problem we run into is when you have LOTS of really small sites.  That's still an issue due to the Task server requirement on those sites.  It can be managed, but not very well.  So, for our customer that has 1000 sites, yeah, it's still a problem.  But we're already actively retooling that.  All we have to do is break-away from the Task Server requirement and we'll get there as well.

All that said, if you know of specific issues, let us know.  I'd be interested to hear why it doesn't work for 1K clients.

In several of the posts here I've seen people not just post complaints and/or suggestions, but questions as well.

Note: They'll be missed by everyone else!  Open up a new thread so we can see what you need.  We have a LOT of people, for instance, that have successfully rolled out sites. There should be NO problem in that area, but if you post it here, then there's a good chance that anyone who has already been the rounds in this thread will miss it.

Just a thought.

First of all My apologies, I thought this was a new post - can it be moved?

Second, where is this documented:  "...AND the agent prep so that the image can be deployed anywhere....."

I looked everywhere

If the PXE components are not going on the new Site Server,

-- they did

then the new Site Server isn't a package server AND task server already.

-- It is

 Without those, the policy doesn't apply.  

--i agree

We have this documented, and we have a support "Quick start" to help you through these.

--Yeppers - read em' many times

 Additionally, we have a KB on "adding a site server after the first one" or something like that - specifically for the issue you're asking about.

The services are runnin but when you go to Settings -> deployment -> PXE server configurations, the site server does not show up.

We've been down these roads.  The information is there.

-- i agree, i went to far down the road, I lost track of where home is now.

I will start a new post asking help for getting the site server to show up.