Stop using 'c:\temp\' in debug-script as output location
launched
Scott Thomson
'C:\temp' is a bit of 'why are you doing that, MS provides you with sys-level and user-level temp areas' - and it contributes to leaving behind junk on systems when it doesn't need to. Windows has native 'clear temp' functionalities - so it'd be nice if you didn't re-invent the wheel and create your own temp dirs. outside those.
I was going to ask that the debug script also be context-sensitive regarding which user it runs under - this is specifically for things like RMM (Example: our 'remote CLI' runs as SYTEM [nt authority\system]; but it MIGHT be sufficient just to use the envVAR the MS provides you - for example, '%TEMP%'.
If a normal user invokes, output should direct to user-profile temp, that is: C:\Users\<user>\AppData\Local\Temp
if invoked via RMM tooling (at least in our case), %TEMP% for 'system' resolves to C:\windows\temp
I see mention that in certain contexts 'system temp' MAY be as follows - might just be if its a service? Not sure of specifics, but IF this is appropriate I wouldn't object:
C:\Windows\System32\config\systemprofile\AppData\Local
C
Carl Levine
updated the status to
launched
The link in our documentation was not up to date, and this has now been rectified.
The newest version of the debug script utilizes a permanent link location in S3. If this new version does not perform as expected, please create a support ticket at support@dnsfilter.com from an email address associated with your account.
https://s3.amazonaws.com/download.dnsfilter.com/User_Agent/Windows/diagnostics.bat