Since upgrading to 7.5 can't deploy packages

[amandaw33]

I'm having trouble pushing images since upgrading to 7.5 yesterday.  Haven't tried uploading an image yet.

Found the DSTasks.log thanks to other post and error seems straightforward - but no idea how to address.  I confirmed the image files are on the server 

[2013/12/31 13:32:14.822 1720:1272 2] Function Name is util::CSMPPackage::Initialiaze(),file name is common\util\SMPPackage.cpp and Line no 93.  Package Server is not found for package with Guid 6c2a2be7-cfa2-4d91-8df6-0ea43aaa230d. It may be that package is just created and not ready yet or package have not synced on nearest packages server. Please try after sometime.

2013/12/31 13:32:14.822 1720:1272 0] File:common\util\ExecuteCommand.cpp,Line:4303 ERROR: Exception has occured in File SMPPackage.cpp at Line No 94. Type of exception is GeneralError. Error is Package Server is not found for package with Guid 6c2a2be7-cfa2-4d91-8df6-0ea43aaa230d. It may be that package is just created and not ready yet or package have not synced on nearest packages server. Please try after sometime.. Error Description is  "util::CSMPPackage::Initialiaze". Value of Windows error code = 183 and message is " Cannot create a file when that file already exists.

I noticed for the filter "package servers" my NS isn't listed, but it is listed under "out of sync site servers."  Our environment is pretty small so our NS is where we host everything - though SQL is on another box.  Is this the route of my problem?

 

I put a ticket in as well.

[SK]

The SMP is a site server as it runs the task service; however, it does not run the package service as it is able to service package download requests without that service, and we do not recommend installing the PS onto the SMP.

The logs are expecting a site server running the package server to have that package.  Best practice is to have a standalone site server in the same subnet as the SMP that runs the package service in order to remove that performance load from the SMP.  As the task service on the SMP can only service around 500 nodes, it is also best practice to have the task service also running on that site server, and to configure the SMP's task service to either only service other site servers, or to not service any nodes what-so-ever.

[amandaw33]

Hi SK,

Thanks for replying.  We are right around 500 clients and we reimage machines rarely (~5 a month, except every 4 years we do a bulk reimage when new machines come in).

Is this new with 7.5?  I did read about the recommendations for the package service being off loaded, but it's surprising to me the upgrade just disabled something that we had working fine previously, if that's what you're saying happened.

[SK]

If you only have around 500 nodes then there really isn't a need for a seperate site server.

I'm new to 7.5 as well, and just went off of what the log entry stated, and cannot say why DS is expecting a PS instead of using the SMP directly.

 

[Migration User]

Sally,

You do not need to have a separate package server unless you want to image using HTTP.

In DS 7.5, DS will always try to image using HTTP first. If this hasn't been configured (using the "Deployment Package Server Components" policy), then it will default back to a UNC path and imaging will still function properly.

If you only have one SMP (NS server) it will act as a package server even though Package Service isn't technically turned on.

I'm not sure about your log entries, especially the "out of sync" part, but the logs should always show that they are trying to find a Package Server first and then when that fails, it should find and use your NS computer.

 

Rick

 

[Migration User]

Sally,

 

Have you installed HF1 & 2?

If not, these may clear up some of your problems.

[amandaw33]

Yea I installed all hot fixes available.  Thanks again for the replies.

[amandaw33]

Hi Rick,

When you said "if this hasn't been configured (using the "Deployment Package Server Components" policy)" - are you talking about the agent install policy?  

I have that install policy enabled.

Filter for "Computers with latest Deployment Package Server Component installed" shows no computers though.

It's not clear to me if I am using NS server to host packages, if NS server should be showing in that filter or what.  

Hoping support can get back to me today.  

[amandaw33]

This is the response I got from support.

"  I checked with my backline team can you installing the package server on the NS by default NS is package server but can you try installing that manually and try deploying the image"

I asked for more clear instructions.. if anyone can shoot me towards a KB I should be following let me know.  

[SK]

NO, do not install the package service onto the SMP.  We do not recommend doing this as the SMP already provides package download services without that service, and installing that service will cause it to have the majority of packages twice within its filesystem.

I honestly find it hard to believe that we would ask you to do such a thing!

[amandaw33]

That's why I posted here, it sounded fishy. I don't want to make it worse.  Thanks for replying so quickly SK.

[Migration User]

Sally,

The "Deployment Package Server Components" are installed usning the "Deployment Package Server Components" policy as follows:

1.  From the Symantec Management Console's menu bar, select Settings > Agents/Plug-ins > All agents/Plug-ins.

2.  Now from the left pane, select Deployment and Migration > Deployment Package Server Components. This is the policy that will install the DS Package Server software.

It is this policy, which is enabled by default, that will enable HTTP imaging on a Package Server. This package server must be a Windows based machine running IIS 7.0 or later.

As has been previously mentioned, the default package services that run on the Notification Server is not a true package server, therefore, it will not run this policy unless Package Services are installed on the NS computer.

Keep in mind, however, that HTTP imaging is only an option and not a requirement. If everything is working properly, imaging should take place whether or not the "Deployment Package Server Components" have been installed or not.

Rick

[amandaw33]

Still hoping to work with support on this, know they're busy.

Things I figured out so far

1) I get a error in 1st post when trying to restore disk images created with 7.1

2) Error in first post from dstasks.log mentions GUID 6c2a2be7-cfa2-4d91-8df6-0ea43aaa230d.  I don't know if that's supposed to match a GUID (folder name) in my images folder, but it doesn't.  The folder this image is stored it starts with e7

3) I get an error when restoring backup images created with 7.1.  Error in dstasks is "[2014/01/02 14:40:57.604 1716:716 2] Function:util::CNetShare::DoMapping,File:common\util\NetShare.cpp,Line:124.Using IP -> Z: have failed in mapping to \\cms\Deployment\Task Handler\image\c6be889b-f8eb-4ab2-b766-9f7faef2b183. Windows Error Code is 67"

4) The guid in the error for the backup image matches the folder name where the backup image resides.

5) I can create and restore a new backup image.  When restoring a new backing image created with 7.5 it gets the image file from "\\cms\NSCap\bin\Deployment\Packages\Images\guid".  When I browse to that location, the only image there is the one I created today.

I'm working now to see if I can create/restore new disk images, but my guess is yes.

[amandaw33]

One more update - I was able to create a disk image (will try restoring it tomorrow but i'm sure that works).  It stored it in the new location in nscap.

Could my problem be a simple as I just need a share point set up for the old images location?  Or was the upgrade supposed to migrate them, and something was missed because my NS is also handling my images where most use package servers?  

Though that doesn't explain if the GUID for the disk image error should match a folder name in D:\Altiris\Altiris Agent\Agents\Deployment\Task Handler\image (cause it doesn't)

 

 

[JanTorsten Hobohm]

Isn't your problem, that after migration all your old 7.1 images are missing? Check TECH211962

Do they still exist in the old location "D:\Altiris\Altiris Agent\Agents\Deployment\Task Handler\image"?

Which path is shown in the console "All Settings > Deployment and Migration > Images" for one of these images?

I know you read that tech article, but maybe everybody is misled by the log talking  of "package servers".

 

 

 

[amandaw33]

Yes the images are at the old path, I guess the upgrade was supposed to migrate them to the new location but it didn't seem to.

Path in console is to the old location.

It does seem some variant of http://www.symantec.com/business/support/index?page=content&id=TECH211692 - but in my case the images are on the server and are in the console.

Hoping to get somewhere with support on it Monday.  

[JanTorsten Hobohm]

You could try to copy the images to the new location in nscap and update the path in the packages in your console.

[amandaw33]

thanks for the idea, no-idea.

Tried that, at least the console now sees the package path as valid.  It still won't deploy though.  Console says "waiting for agent to get task" and SMP.log on client shows 'unable to update active task list'

hopefully I can get somewhere with support today on it.

[amandaw33]

Update - no-idea's solution worked.  Maybe I wasn't patient enough the first time I tried imaging a client this morning.

So, I'm moving all images to new location and updating paths.  There seems to be no place in GUI to update backup image paths, but I can live without those.  One of my disk images was missing from the old location (out of 15 or so), I restored that from a backup.

My biggest issue now is when restoring these 'old' 7.1 images, they boot to production fine but the agent soon reports "reboot to production" failed and all tasks I have set to run after that don't run because of failure.

Support told me I need to update the images, that this is happening because they have the old client.  While mostly we use one hardware independent image, it will suck to have to update the other ~14.  I swear this came up for me before in a prior upgrade and I didn't have to update images.. any suggestions on that?  

 

 

[JanTorsten Hobohm]

Put your single reboot task into a new job 'reboot to prod' and uncheck 'Fail job if....'. Now in your image restore job replace the old task with the new job. The task will still fail, but not the whole job.

[amandaw33]

@no-idea - I thought about that, but then was thinking the agent is going to try to upgrade as soon as it talks to NS... and will fail the proceeding tasks probably anyway.  Maybe I'll try your suggestion and also add in a 'update client config' task in there.  The way the agent reboots itself a few times during upgrade makes me think I'm stuck upgrading all images probably.