Blogs

Troubleshooting Inventory Issues

Anybody know how to troubleshoot inventory on an ecommerce site? Looking for tips...

View comments (1)

Desktop Authority Upgrade to 9.2 breaks MSXML4. A Controlled Upgrade Must Be Developed

We upgraded from Desktop Authority 9.0 to 9.2 and it broke our apps that utilize MSXML4. We called support to find out if they are doing anything with MSXML4 and we were told no and that our AV must have interfered. This is NOT correct. I unzipped the Desktop Authority msi package DAClientInstall.msi and TADA, inside was 4 DLL's having to do with MSXML4. The upgrade to DA 9.2 is breaking MSXML4. We are a hospital and this affected our ER and we had to declare a patient safety issue because we couldnt admit patients. All of this could have been avoided if Desktop Authority had a way to do the upgrade in a controlled manner and NOT resort to the shotgun approach. To me this demonstrates a small business mentality on their part. Upgrading the server to the new version and then it upgrading ALL the agents is completely unacceptable, especially in a large organization.

So to my question. Will Desktop Authority ever develop a way to upgrade their software in a controlled manner?

I will NOT upgrade again unless they develop a way to do it in a controlled manner. If they dont I will be looking for a replacement.
The ability to control the upgrade in a controlled fashion MUST be developed. This is unfair to the customer. I am going to explain all this to support and lets see if Dell does anything about it.

As a side note this is twice they broke our environment. The first was upgrading from 8.1 to 9.0. Their group policy deployment mechanism caused us to be in a loop of the GPO trying to install the old version 8 and when you logged in, it tried to install version 9.

View comments (2)

Desktop Authority Upgrade to 9.2 breaks MSXML4. A Controlled Upgrade Must Be Developed

We upgraded from Desktop Authority 9.0 to 9.2 and it broke our apps that utilize MSXML4. We called support to find out if they are doing anything with MSXML4 and we were told no and that our AV must have interfered. This is NOT correct. I unzipped the Desktop Authority msi package DAClientInstall.msi and TADA, inside was 4 DLL's having to do with MSXML4. The upgrade to DA 9.2 is breaking MSXML4. We are a hospital and this affected our ER and we had to declare a patient safety issue because we couldnt admit patients. All of this could have been avoided if Desktop Authority had a way to do the upgrade in a controlled manner and NOT resort to the shotgun approach. To me this demonstrates a small business mentality on their part. Upgrading the server to the new version and then it upgrading ALL the agents is completely unacceptable, especially in a large organization.

So to my question. Will Desktop Authority ever develop a way to upgrade their software in a controlled manner?

I will NOT upgrade again unless they develop a way to do it in a controlled manner. If they dont I will be looking for a replacement.
The ability to control the upgrade in a controlled fashion MUST be developed. This is unfair to the customer. I am going to explain all this to support and lets see if Dell does anything about it.

As a side note this is twice they broke our environment. The first was upgrading from 8.1 to 9.0. Their group policy deployment mechanism caused us to be in a loop of the GPO trying to install the old version 8 and when you logged in, it tried to install version 9.

Be the first to comment

Changing the Auto-LogonCount in the unattend.xml file at deployment time.


When creating an Image or Scripted install the AutoLogon count must be set. However certain Post Install tasks require a reboot so adding (or removing ) such a task changes the requirement for the AutoLogon Count of the Unattend.xml file. If you're working with a Scripted Install one can directly edit the unattend.xml from the detail page. If working with a Kimage one has to download the unattend.xml file, alter it and upload back to the image. An extra step but on the whole not too bad. Wim images are another matter, changing the unattend.xml file in a Wim image is very difficult.


You can solve this problem by installing the Change AutoLogin Count task. It will show up as a mid level task which you can add to an image. It will work for Kimages, Wim images, and Scripted Installs. The task itself is a Template so once installed, duplicate the task and make appropriate changes to the copy. The template task sets the Auto Logon Count to 6, turns on the debut option, and uses the default location for the unattend.xml file. Change the duplicated task settings to suit your needs.


It is recommended the duplicated task's name be changed to reflect the Auto Login Count number specified on the command line for that task.

If the task sets the Auto Login Count to 6 the name might be “set autologin count 6” to avoid confusion with any other duplicate tasks

that set the count to something else.


The task takes up to three command line arguments


-cXX where XX is an integer from 0 – 99 note there are no spaces between the -c and the XX


-pPATHTOUNATTEND.XML where PATHTOUNATTEND.XML is the full path (including the drive letter )

to the unattend.xml if your Image or SI does not use the default OSDRIVE:\windows\panther\unattend.xml

note: there are no spaces between the -p and the full path. If the path has spaces in the names

it must be surrounded by double quote marks.

Example : -p”C:\windows\other path\unattend.xml”

the unattend.xml MUST be included in the PATHTOUNATTEND.XML argument


-d This is the debug option. When included, full details of the task run will be written out to the

\\k2\petemp share with the name MAC_set_auto_count.log where MAC is the mac address of the machine

on which the task ran.

The -cXX argument is required while -p and -d are optional.


When running, if the task fails it will usually provide an error code to the task manager. Reference the return code below for the most common failures.


10 no windows drive could be located. A DRIVE:\windows folder could not be found.

11 Invalid number of arguments must be 1 to 3. There must be at least 1 and no more than 3.

if there are spaces in the -p option inclose it with double quotes

12 invalid argument -cXX, -pPATH, and -d are valid

13 the -cXX argument is required

14 the -cXX the xx must be an integer in the 0 - 99 range

15 the -pPATHTOFILE requires the PATHTOFILE exist

16 no autologin entry was found in the unattend.xml file


If the task fails to work as expected, add the -d option to the command line and look for the debug file on the \\k2\petemp share.


Back to the K2000 Deployment Workbench Page


Be the first to comment

App-V 4.6 to 5.0 migration issue....

Hi guys,

i am working on CAS CARLISLE GROUP 5.0, i converted this appllication from 4.6 to 5.0 and launched the shortcut CAS 5.0  then i am getting the below error

FILE ERROR 2 The system cannot find the file specified.
InitializeDll[5] ŒNA'I ',path,'|AuditLicense =I4'
                ^
------------------------------
#.Library.Activation.InitializeDll[5]
#.Library.Activation.constructor[4]
#.CAS3.DoActivation[5]
#.CAS3.RTRUN[7]

This shortcut is pointing to ""C:\PkgConvertMount\CAS 5.0\dyalogrt.exe" CAS inifile="HKEY_LOCAL_MACHINE\Software\CarlisleGroup\CAS 5.0".

 

Can any one advise me to how to solve the issue..

Thanks in advance..

Be the first to comment
Showing 1 - 5 of 2570 results