2 Replies Latest reply on Oct 4, 2011 3:10 PM by lonniesohm

    Error code 16389


      I have a bit of an issue that I can't seem to resolve and need some help.  I have searched all the "error 16389" posts in the LANDesk community and outside it, and have tried every combination of possible solution, but none seem to work.


      I have a virutal test environment that I just setup.  I am using Virtualbox as my environment. 

      • I have 2 XP 32-bit machines, 2 XP 64-bit machines, 2 Win7 64-bit machines, and a Windows 2008 R2 (64-bit) Server with LDMS 9 SP2 running on it. 
      • The virtual network is setup as a Workgroup (no, I do not want to make a domain in my VM), and all the machines are setup as HOST ONLY. 
      • My LDMS server has a static IP address, but all the other machines are getting their IP addresses from the DHCP environment of Virtualbox.
      • The 32-bit machines are using the PCNET-PCI II network drivers, but the 64-bit machines won't work with it, so they are using the Intel Pro 1000 MT Desktop network drivers.


      I can push the LANDesk agent to every machine, 32-bit and 64-bit.  I can remote control every machine from the LDMS Console, run an inventory, etc.  And I can push software packages to the 32-bit OS's, but I CANNOT get any software package to push to the 64-bit OS's (yes, they are 64-bit compatible softwares).  I can see the communication happening between the LDMS server and the 64-bit machine I'm pushing to by watching the 'Network Activity' indicators on both VM's, and I see the first handshake, then the last, after which the install will fail with the 16389 error.


      I have done the following:

      • Disabled the firewall.
      • Disabled UAC, both through the GUI and through the registry hack seperately, just to be sure.
      • Disabled 'Simple File Sahring'.
      • Removed any anti-virus softwares.
      • Verified root level hidden file share (C$), and manually set other file shares.
      • Changed the installation packages from 'LocalSystem' to 'Current User's' accounts.
      • Reset package hashes and recreated scheduled tasks.
      • Rebuilt the packages from scratch.
      • Changed the LANDesk Management Agent service from LocalSystem to an Administrator account.
      • Set every variation of alternate logon account credentials in the LDMS Scheduler on the LDMS machine.


      After attempting to push a software to a machine, the local event log on the 64-bit machines show that the push signaled an open state of the LD Service, then a close state - no errors.

      I have launched a Command Prompt as an administrator and tried any 'Net Use' command from the workstation to the LDMS server, and I get prompted that a correct username and password are required, so LocalSystem is not properly communicating with the LDMS server.  However, if I change the Logon Account for the 'LANDesk Management Agent' to a local account with administrative priviledges, that fails too.

      Also, if I change my distribution package from 'LocalSystem' to 'Current User's Account', it still fails.


      So, as you can see, I have tried every potential soultion I could find on this issue, but to no avail.  I tried porting my VM's from Virualbox to VMWare Player, but they fail (we don't have any licenses for VMWare Workstation, and was told no on purchasing one), so using another VM is not currently an option and I need to get it to work in Virtualbox.


      Any help is GREATLY appreciated!  If I had hare, I'd be bald by now trying to get this to work...!

        • 1. Re: Error code 16389
          MarXtar ITSMMVPGroup

          I don't know what you are trying to send, but instead of using UNC (which is tricky at the best of times, never mind when you don't have a domain to handle rights), try using http for the package source. At least then you won't have windows rights as a barrier to your testing.


          Concentrate on getting something transferred to those machines rather than installed. The issue seems to be it cannot locate/access the files which is generally name resolution or rights to the source location.


          I know you said you didn't want to make a domain but I'd also seriously consider setting up a domain within your VM environment if you want this as a proper test bed. I don't know why you don't want to, but if it is time related you have probably spent more time troubleshooting, and if it is memory related, mine runs happily with between 300-400MB ram assigned to my AD server (just takes a while to start). If you have that in place then you are truly able to replicate the permissions structures that you would encounter in the real world and be able to do things like adding computer accounts with rights.


          Mark McGinn

          MarXtar Ltd



          The One-Stop Shop for LANDesk Enhancements

          - Wake-On-WAN - Distributed Wake-On-LAN, Scheduled Power Down, and SWDist Sequencing

          - Inventory Archiving/Change & Root Cause Analysis

          - Self-Service Password Reset

          - PC Power Management

          - Help/Service Desk Integration

          - LANDesk Data Manipulation/Integration/Bar Coding

          - LANDesk Executive Reporting Pack

          - Network Asset Discovery and Management

          - LANDesk Software Store

          • 2. Re: Error code 16389

            Brilliant!  Thank you!


            It took me a little bit to get around in IIS in Server 2008 as it's far more granular, but once I got it working right, BAM!  Packages are pushing to my x64 machines!  I had to rebuild a couple packages to push properly over HTTP, but that did the trick!


            One answer solutions - thats the way I like it!


            As to setting up a domain in my Host Only test environment, for some reason our network admins are scared our production domain will see and add my test domain.  Mind you, I'm not a Network Admin, but if I remember my domain network basics, I would have to have my test environment setup in a Bridged (and possibly NAT) mode, and actually Promote my domain for it to be seen outside my environment.  Things may be much different with Server 2008, so my knowledge may be old and rusty, but for now because of their fear, I'm forced into a Workgroup only environment.


            Again, thanks very much!  I can now make progress on setting up and testing packages and HII imaging!