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
Carl Levine
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