Package Deployer : cliënts keep showing up in Unassigned group

Hello Mark,

have the packages been built with 10.6.4 already? RMS in the package or downloaded by AutoUpdate (shouldn't really make a difference though). My endpoints drop to the correct group - it might be setup.exe (which is responsible for storing the information fro RMS) and I'll check if my packages contain already the latest versions.

Christian

The switch -G as detailed here needs to be quite specific:

https://community.sophos.com/kb/en-us/12570

Note:

The path:

• is case sensitive
• must not end in a backslash
• must include the management server
• must be enclosed in "double quotes" if switches (backslashes) are used

Example:

"\[SecServerName]\TopLevelGroup\Group"

Do you have a screenshot of the SEC group tree and the switch actually being passed by the Deployment packager to setup.exe to ensure they line up with the above conditions?  To get this I would suggest running Process Monitor (technet.microsoft.com/.../processmonitor.aspx): Then look at the process tree to see the full command line.

Regards,
Jak

Hi Jak,

Just used the procesmonitor. When i filter the log and search for "GroupPath" i get no result. Thats also the case when searching for specific words of the group string in the path colum.

Looks like the setup does not create the registry key during installation.

I check the setup.exe that is used during creation of the package. The File version is 3.4.0.271 and product version is 3.4.0.

Hope to hear from you. (Or somebody else who can help me out :) )

Mark

Hello Mark,

3.4.0.271 is current for 10.6.4.

As for Process Monitor - make sure you're capturing registry activity (well, of course you did), use a filter Path contains Sophos\Remote Management System\ManagementAgent. This should reduce the amount of output.

Do you build the package with the GUI or command line? The package can be unpacked e.g. with 7zip, there's a setup.vbs which calls setup.exe - you could check if it's called correctly. As far as I can see the GUI can handle blanks in the group names, could it be some "funny character" though?

Christian

Hi Christian,

Thank you for the input. Feel stupid i did not try to unpack the package yet :(

I just did and one thing i notice is that it seems that the install string does NOT include the -G switch?

Set wshShell = WScript.CreateObject ("WSCript.shell")
wshShell.run sDstFolder + "\setup.exe -crt R -s -mng yes -updp " + Chr(34) + "http://sophosurl/SophosUpdate/CIDs/S000/SAVSCFXP" + Chr(34) + " -user XXi-XX\SophosXXDeploy01 -opwd BwjvkRM7N" + Chr(32) + scriptArgs,, true
oFSO.DeleteFile sDstFolder + "\cid_packager.tmp"

Do you know what the "Chr(34)" parameter does?

Thank you for your assistance.

Mark

Hello Mark,

Chr(34)
is the character represented by decimal 34 or hex 22 and is the double quote ("). It's used to "protect" those double quotes which have to be passed to the shell (similarly the blank: Chr(32)).

You are building the package with the GUI (BTW, which version of SDP - 1.2.x or 1.3) putting the -G in the Additional setup parameters field or from the command line?

Christian

Hi Christian,

Yes we are creating the packages using the GUI. We tried 1.2.1 and 1.3. And we are putting the -G in the additional setup parameters and it does not contain any "funny cararacters".

Have not tried to create the package through the command line though.

Mark

Created the following line in my setup.vbs

wshShell.run sDstFolder + "\SAVSCFXP\setup.exe -crt R -s -mng yes -g \server\group" + Chr(32) + scriptArgs,, true

Do you have any additional parameters?

Can you paste the contents of the field here?

Regards,
Jak

Hello Mark,

I've used both the GUI and CLI of the SDP since it came out, never had an issue with -G (or -g).

Hm ... hm .... this is weird! If I copy/paste the example grouppath from your post ... no, just the -G ... again, no: just the – suffices, and -hey!- it's not a - dash but an –. Looks normal when I copy it into the GUI's field but then there's no output of the part from the ndash up to the next recognized switch. Any chance there is this funny character?

Christian

Hi Christian and Jak,

Well, were do I start.. :)

Yesterday i got informed by a colleague that he used a package that did put the agents in the correct group. I investigated the package (extracted it and looked at the setup.vbs) and that did contain the -g string. The package i created did not contain it. So i tried to create a new package and suddenly it does contain the -g string! But... this old package was created in november 2016! One of the things i now is that 3 days ago an update of the SEC has taken place. Maybe that corrected the issue of the -g string not showing up in the setup.vbs.

I rolled out a test server and when executing the packages i runned the process monitor. Filtering the path column for the value "GroupPath" (without the quotes) i saw the regcreate action pass. The strange thing now is that the old 2016 package creates the string and at a certain point the grouppath key is read and deleted. This happens after the reboot i believe. The client from that package shows up in the correct group.

Whileinstalling the new package i just created (containging the -g string) on the server i now see the regcreation action appear, but the GroupPath key is not read, not deleted and thus the agent doen NOT appear at all in the console.. What the ... This this is bottering me as .... :)

But there is progress.. :)

Not tried running the CLI of the SDP, but as far as i can see it appears to not be an issue with the SDP. The registry entries created by the setup are looking fine. No spaces, no funny characters (except the _, but its there in the working package as wel) i checked the space, to be sure there is not a &ndash..

Below some screendumps i collected.

The top part is when i was installing the package that did NOT contain the -g swith in setup.vbs
The middle part is the package that contains the -g switch in the setup.vbs and where it is not read, deleted and the agent does not show up in the console. Where it did before in the unassigned group. I believe i took this before a reboot. I am not sure anymore. I can recall that the lines that are not showing (the ones that do in the toppart) are there after the reboot. As well as the grouppath key.

Well... hope to hear from you guys again :).

Thank you ,

Mark

Hi Christian,

I just replied tho Jak's post, so this is a reply so you receive a notification. :)

Mark

Hello Mark,

[note: if one is subscribed to a thread he or she receives a notification of all replies/appends - but thanks for keeping me in mind]

First of all, an installation of SDP is independent from SEC or its version (you can run SDP on any -Windows- machine, it only has to be able to access the required CID). If the -g is not in the .vbs then it was SDP's deed. Can't say why the minus/hyphen wasn't one but I'm pretty sure this was the cause. I've run SDP literally dozens of times and as far as I can see the logic is simple and while it is not absolutely flawless it doesn't drop a token starting with a hyphen. Anyway you can always check the resulting VBS if you are paranoid [;)].

Whenever the Sophos Agent service starts it checks for the existence of the GroupPath value and if present it sends the respective message to the management server and deletes the value.
The Agent is installed as part of RMS which is the first component that AutoUpdate installs on a managed endpoint. Can't recall that it'd require a reboot though.

but the GroupPath key is not read
is the Sophos Agent service started? As said, it should always check during start-up (as Moving a computer ... describes), if not there's something not working as it should and this'd be a case for trace logging (not that I think you'd need it).

Christian 

Hello Mark,

[note: if one is subscribed to a thread he or she receives a notification of all replies/appends - but thanks for keeping me in mind]

First of all, an installation of SDP is independent from SEC or its version (you can run SDP on any -Windows- machine, it only has to be able to access the required CID). If the -g is not in the .vbs then it was SDP's deed. Can't say why the minus/hyphen wasn't one but I'm pretty sure this was the cause. I've run SDP literally dozens of times and as far as I can see the logic is simple and while it is not absolutely flawless it doesn't drop a token starting with a hyphen. Anyway you can always check the resulting VBS if you are paranoid [;)].

Whenever the Sophos Agent service starts it checks for the existence of the GroupPath value and if present it sends the respective message to the management server and deletes the value.
The Agent is installed as part of RMS which is the first component that AutoUpdate installs on a managed endpoint. Can't recall that it'd require a reboot though.

but the GroupPath key is not read
is the Sophos Agent service started? As said, it should always check during start-up (as Moving a computer ... describes), if not there's something not working as it should and this'd be a case for trace logging (not that I think you'd need it).

Christian 

Hi Christian and Jak,

Been a while, but i have been working with al your info in the past weeks. It is not completely clear but the last 2 installs went wel. I do check the VBS in the package to check wether it contains the -G switch. En besides that i created an entry in our shutdownscript (We use Citrix Xendesktop/XenApp) that adds the GroupPath key in the registry. In that way i am sure the entry is there when a new machine boots up and the machine is put in the correct group.I still have to check the environment it went wrong last time, but i think i will sort that out.

I want to thank you guys for your help and input. It is appreciated!

Regards,

Mark