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,

Checked that article several times and tested with various otions of the ". I am sure the SEC group tree is correct. I will check with process monitor as soon as i can.

Thank you for your reply!

Mark

Hi Jak,

I did not run processmonitor yet, but have tested the installation by using the command line. And that works!

The command I used:

setup.exe -mng yes -updp http://Updatepath/SophosUpdate/CIDs/S000/SAVSCFXP -ouser ObfuscatedUsername -opwd ObfuscatedPassword –G "\Subfolder\Subfolder\Subfolder" -s -ni

So at least I know that it is not on my serverside, but probably in the packages that we build with Deployment Packager. Strange thing is that i already downloaded the most recent version of that (1.3.1).

Any Clue?

Thanks,

Mark

Well the -G switch and the value passed to setup.exe with it, just gets stored in the registry temporarily before the Sophos Agent Service (part of RMS - ManagementAgentNT.exe) can get installed, start-up, read the key, delete the key and create a message for the management server to move the computer to the specified group.

You could check that the GroupPath value under HKLM\Software\[wow6432node]\Sophos\Remote Management System\ManagementAgent is being written before the Sophos Agent service starts up, reads it and deletes it. 

I think the PML log will show all of this taking place.

Regards,

Jak

Well the -G switch and the value passed to setup.exe with it, just gets stored in the registry temporarily before the Sophos Agent Service (part of RMS - ManagementAgentNT.exe) can get installed, start-up, read the key, delete the key and create a message for the management server to move the computer to the specified group.

You could check that the GroupPath value under HKLM\Software\[wow6432node]\Sophos\Remote Management System\ManagementAgent is being written before the Sophos Agent service starts up, reads it and deletes it. 

I think the PML log will show all of this taking place.

Regards,

Jak

Hi Jak,

Sorry for the delay!

A few days ago i performed an installation by using the commandline. I also used obfuscated credentials and the -G switch. This time the agent was put into the correct Group!

A few moments ago i installed an agent using the created package and i monitored (using F5) the registrypath you mentioned. I do not see the key GroupPath appear in this folder. I realise that it might process so fast that i might have missed it. So i am now going to try and use the PML. But that just gives so much output.

I attached a screenshot of the registry. From beginning to the end (it starts with installing RMS) these keys are created and present at the end of the install.

Thank you for your help so far.

Mark

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