Video Screencast Help
Search Video Help Close Back
to help
New in the Rewards Catalog: Vouchers for "Symantec Technical Specialist" and "Symantec Certified Specialist" exams.

Console remote install default share

Updated: 22 May 2010 | 9 comments
jackrungh's picture
+1 1 Vote
Login to vote
This issue has been solved. See solution.

I have searched for a resolution to my issue for several days now while configuring and testing GSS 2.5. I'm pretty surprised that this situation hasn't come up before.

To do a remote install from the console it appears that the administrative share c$ is used as a vehicle. If I add this share to client machines it works without issue. The problem is while I might be the local administrator for my division, I do not have administrative access to the global domain. Group policy wipes out any administrative share that exists, except for the default used by our stock image, IPC$. I would prefer not to go machine by machine and setup a logon script to add c$ every boot, as there are hundreds of machines. I have tried to find a registry key, config file, anything to change the console's default route to the IPC$, if that were possible it would be effortless to get the client distributed. For now I have created an internal website for employees to manually go and install the client, but any uninstalling/reinstalling requires the share, as well as perhaps many other console actions that I haven't explored yet.

So.. Is it possible to edit this value from c$ to ipc$? Can I circumvent the problem alltogether by setting up packages with a console client 3com services partition?

I'm still very green to this suite so I may be making things more difficult than they need be. Please advise.

Comments

Randall Newnham's picture
22
Mar
2010
1 Vote +1
Login to vote

MSI file

Hi there,

Unfortunately, the remote Client Install tool is hardcoded to use the C$ share. I would advise making a group policy to run the client.msi to install the client. Here is an article on setting up the msiexec command line:

 How to silently install Symantec Ghost

jackrungh's picture
23
Mar
2010
1 Vote +1
Login to vote

Unfortunately I have no

Unfortunately I have no access to implement group policy, that is above my pay-grade. As I said I got the client installed on a few dozen machines during this testing phase, and I have run into another issue. I needed to reimage the server running the Ghost Console for reasons not associated with GSS, and now that I bring it back up to same static IP and hostname, clients installed on the workstations will not connect back. I have a suspicion that this is pubkey.crt related, but as I said all of the particulars for the console machine are the same.

Randall Newnham's picture
23
Mar
2010
1 Vote +1
Login to vote

pubkey

There is a tool for redistributing the pubkey.crt to existing clients. Here is a link to an article and the download:

 How to distribute the "pubkey.crt" file to multiple client computers

jackrungh's picture
24
Mar
2010
1 Vote +1
Login to vote

Thank you for your attention

Thank you for your attention to our questions Randall.

The link you posted is broken, but I have updated to 2266 and need to update clients anyway, so I have decided to not fight city hall on this.

I am building our new stock images and will include in them a batch file to create a C$ at startup. This will allow management of active workstations, and yesterday I configured a console client PXE image so that nonfunctional ones will respond as well. This pretty much covers the bases, but I am running into another issue concerning deployment of the correct client version to existing machines. The idea is that we need to get the client on all current machines, pull user data, apply the images to new hardware coming in, and then restore user data from console to the new machines.

So I read up on the msiexec install method for the client and came up with this:

@echo off
if exist "C:\program files\symantec\ghost\ngctw32.exe" goto uninstall_first

echo Installing the new client...
Msiexec /q /i "\\xxx.xxx.xx.xx\Client\Client.msi" GHOSTINSTALLTYPE="Client" GHOSTCONSOLESERVERNAME="xxx.xxx.xx.xx"
echo Success
goto exit
 
:uninstall_first
echo Uninstalling the old client...
Msiexec /q /x "\\xxx.xxx.xx.xx\Client\Client.msi"
echo Success
echo.
echo.
echo Installing the new client...
Msiexec /q /i "\\xxx.xxx.xx.xx\Client\Client.msi" GHOSTINSTALLTYPE="Client" GHOSTCONSOLESERVERNAME="xxx.xxx.xx.xx"
echo Success
goto exit
 
:exit
echo.
echo.
echo Finished
pause

The problem is that the GHOSTCONSOLESERVERNAME argument appears to do nothing, the client will uninstall no problem, install no problem, and then proceeds to search for a server, which in my environment is not acceptable. It does not take an IP (preferred) value, the computer name, full hostname, anything. This is supposed to work, any ideas why it isn't?

 

Randall Newnham's picture
24
Mar
2010
1 Vote +1
Login to vote

quotes

Hello,

I believe the GHOSTCONSOLESERVERNAME takes an argument without quotes... have you tried that?

Thank you,

Randy

jackrungh's picture
24
Mar
2010
0 Votes 0
Login to vote

Yeah I have tried with

Yeah I have tried with quotes, without, examples of whitespace and no whitespace, everything uninstalls/installs no problem but it appears that the GHOSTCONSOLESERVERNAME argument performs no action. I have tried without the silent install flag, and manual entry of the same values is flawless, instant connection to the console.

jackrungh's picture
25
Mar
2010
0 Votes 0
Login to vote

Well, I am sort of at my wits

Well, I am sort of at my wits end with this silent installer. The ghostconsoleservername refuses to work. It installs and searches for the first server it can find, which is always the wrong one. If I allow the install to run with user interaction and enter the IP myself at the prompt it instantly connects to my console server. I have tried every variation of possible syntax I can think of on multiple machines and it just doesnt pull the value. It is as if it isnt reading the argument at all.
I cannot find anyone else who seems to have this issue, so I am wondering if there is anything systemic in my environment that might be preventing client.msi from evaluating ghostconsoleservername?

jackrungh's picture
25
Mar
2010
0 Votes 0
Login to vote

Property(S): CURRENTDIRECTORY

Property(S): CURRENTDIRECTORY = C:\Documents and Settings\userwashere
Property(S): GHOSTCONSOLESERVERNAME = xxx.xxx.xx.xx
Property(S): PackagecodeChanging = 1
Property(S): ProductState = -1
Property(S): PackageCode = {codewashere}
MSI (s) (1C:88) [10:51:40:109]: Product: Symantec Ghost Console Client -- Installation operation completed successfully.

=== Logging stopped: 3/25/2010  10:51:40 ===

used /l* msiexec flag to produce this log. seems that it is taking that IP, but not applying it.

Further up there is also:

Property(S): SecureCustomProperties = GHOSTCONSOLE;GHOSTSERVER;GHOSTPERSONAL;GHOSTTRIALWARE;GHOSTLATERVERSIONINSTALLED;GHOST70;GHOST75;GHOSTOLDCLIENTUPGRADE;GHOSTCLIENTUPGRADE;GHOSTUSEEXISTINGCRT;GHOSTINSTALLTYPE;GHOSTPRODUCTNAME;COMPANYNAME;USERNAME;GHOSTPRODUCTEDITION;IE5INSTALLED;GHOSTUNDOLOGFILE;GHOSTUPGRADE;GHOSTOLDUPGRADE

Note there it has GHOSTINSTALLTYPE but does not use GHOSTCONSOLESERVERNAME. I am wondering if using GHOSTCONSOLE or GHOSTSERVER in the argument might be something to do.

in ngctw32.log:

Checking for Sysprep. Process id: 4892, name: \DEVICE\HARDDISKVOLUME1\PROGRAM FILES\SYMANTEC\GHOST\NGCTW32.EXE
11:34:34 AM xxx.xxx.xx.xx:1346 polling for any server
11:34:44 AM xxx.xxx.xx.xx:1346 polling for any server
11:35:24 AM xxx.xxx.xx.xx:1346 polling for any server
#\Locate{ Product = Ghost, Component = Config_Server, Name = (), Challenge = blah, IPADDRESS = 3464111195U, Response = blah, Modulus = blah, Generator = blah, Public = blah, Session = blah, Have = (Session), Signature = blah, Host = mmondloch, Certificate = blah, Address = 1347 }
11:35:26 AM xxx.xxx.xx.xx:1346 sending status to  148.92.148.106:1347
11:37:26 AM xxx.xxx.xx.xx:1346 sending status to  148.92.148.106:1347
11:39:26 AM xxx.xxx.xx.xx:1346 sending status to  148.92.148.106:1347
11:41:26 AM xxx.xxx.xx.xx:1346 lost contact with  148.92.148.106:1347
11:41:26 AM xxx.xxx.xx.xx:1346 polling for bound server mmondloch
#\Locate{ Product = Ghost, Component = Config_Server, Name = blahblah, Host = mmondloch, Description = mmondloch, Challenge = blah, IPADDRESS = 3464111195U, Response = blah, Certificate = (), Session = blahblah, Have = (Session), Signature = blahblah, Address = 1347 }
11:41:28 AM xxx.xxx.xx.xx:1346 sending status to  148.92.148.106:1347
11:43:28 AM xxx.xxx.xx.xx:1346 sending status to  148.92.148.106:1347
11:45:28 AM xxx.xxx.xx.xx:1346 sending status to  148.92.148.106:1347

long address strings reduced to "blah" and "blahblah"

so one log has the value captured, this log shows no indication of any prebound server

this is 2266 client

jackrungh's picture
25
Mar
2010
1 Vote +1
Login to vote

It seems the guides and

It seems the guides and documentation online are all incorrect. They all say the flag is GHOSTCONSOLESERVERNAME, but obviously that wasn't working. Buried on page 589 Table I-4 of the ghost implementation guide, it lists command line arguments for Client.msi. They are INSTALLDIR, GHOSTINSTALLTYPE, and GHOSTCONSOLENAME. I ran my scripts with:

msiexec /q /i "\\server\path\client.msi" GHOSTINSTALLTYPE=Client GHOSTCONSOLENAME=xxx.xxx.xx.xx

and it worked like a charm. This documentation needs to be changed, I only found it in the implementation guide while I was reading up on command line options for sysprep.

Thanks again Randall, your diligence monitoring and responding in this forum is appreciated.