This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Mr B Jones
Recipients Mr B Jones, paul.moore, steve.dower, tim.golden, zach.ware
Date 2016-12-29.08:38:11
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1483000691.86.0.0496200688253.issue29033@psf.upfronthosting.co.za>
In-reply-to
Content
All those logs came from one machine. SCCM is usually really good at detecting the existence of an install by checking the package GUID in the windows installed database, but getting the right GUID when dealing with a non-msi install is sometimes hit and miss (with a pure MSI install, it just pulls everything out of the MSI automagically). It can also check for the existence of files/folders, and files with particular version numbers embedded in them (though windows seems to display these version number differently than SCCM sees them sometimes).

In this case I guess I got the wrong GUID, so it went on re-trying the install, and all bets were then off. Usually the easiest way to get this right if it isn't automatic from the MSI is install the package then look in the registry for an uninstall or modify string which looks like "msiexec /x {GUID HERE}", but if I remember correctly (and it has been a couple of weeks so I could be thinking of the wrong package), the python installer doesn't do that.

When I'm back in work (from 9th), I can try it again SCCM.

Thanks for all your assistance.
Bryn
History
Date User Action Args
2016-12-29 08:38:11Mr B Jonessetrecipients: + Mr B Jones, paul.moore, tim.golden, zach.ware, steve.dower
2016-12-29 08:38:11Mr B Jonessetmessageid: <1483000691.86.0.0496200688253.issue29033@psf.upfronthosting.co.za>
2016-12-29 08:38:11Mr B Joneslinkissue29033 messages
2016-12-29 08:38:11Mr B Jonescreate