| OS | Script Type | Command |
| macOS | shell | ```shell somecommand -u $username -p $my_pass ``` |
| Windows | Powershell | ```powershell somecommand -u $Env:username -p $Env:my_pass ``` |
| Batch | ```powershell somecommand -u %username% -p %my_pass% ``` | |
| Batch | In order to not transmit the password to a log file accessible on the device, add @echo off before the line containing %my\_pass% and @echo on as the next line. Example: @echo off %SystemRoot%\\System32\\Reg.exe ADD "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon" /v "DefaultPassword" /d "%my\_pass%" /t REG\_SZ /f @echo on | |
| mac0S & Windows | Python | ```python import os os.getenv('username') os.getenv('my_pass') ``` |
A fileset whose requirements have failed will not even show up in the kiosk.
Where possible, avoid piping commands. This increases overhead on the scripts. If pipes are required, try to reduce the quantity of pipes. If nothing else, this makes the scripts easier to read. ```shell $ time system_profiler SPHardwareDataType | grep "Model Identifier" | awk '{print $NF}' MacBookPro11,4 $ system_profiler SPHardwareDataType | awk '/Model Identifier/ {print $NF}' MacBookPro11,4 ``` And other commands may achieve the same result more efficiently without the need to pipe. ```shell $ time system_profiler SPHardwareDataType | grep "Model Identifier" | awk '{print $NF}' MacBookPro11,4 real 0m0.192s user 0m0.071s sys 0m0.049s $ time sysctl -n hw.model MacBookPro11,4 real 0m0.004s user 0m0.001s sys 0m0.002s ``` Consider this for all scripts beyond just requirement scripts. ## Log Script Output By default, Fileset scripts built through the Scripts button are logged. All output is redirected to a unique file per script. If desired, additional information could be redirected to an alternate file.Redirecting output to the FileWave Client log, allows the viewing of those details via the 'Get Log' feature
Redirecting to the FileWave Client log is not possible on windows, since the log file is locked by the client writing to the file.
#### Redirecting Output Output may be redirected using one of the following: macOS: ``` echo "hello" >> /tmp/tmp_log_file.log ``` Windows: ``` echo "hello" | Out-File -Append -Encoding Ascii C:\Temp\my_temp_file.log ``` Better than just redirecting output, consider using the tee/Tee-Object command, such that the FileWave generated log and the redirected log both show the output. macOS: ``` echo "hello" | tee -a /tmp/tmp_log_file.log ``` Windows: ``` echo "hello" | Tee-Object -Variable out | Out-File -InputObject $out -append -encoding Ascii C:\Temp\my_temp_file.log ``` On macOS, all output can be redirected by using the following at the beginning of the file: ```shell #!/bin/zsh exec 1>>/var/log/fwcld.log exec 2>>/var/log/fwcld.log ... rest of script ``` ## Testing Scripts Scripts run by FileWave are run by root or System. As such, scripts should be tested using the same user context to prevent erroneous results. Many commands will yield the same result regardless, but this cannot be relied upon. ### Windows E.g. Running the following command will provide a different output, when ran on a 32bit Windows environment as opposed to a 64bit Windows environment: ``` (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").EditionId ``` 64bit: ```powershell (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").EditionId Professional ``` 32bit: ```powershell (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").EditionId Enterprise ``` Similarly, the user executing a script can have an impact on the outcome. Username itself is a relatively obvious example: ``` $Env:UserName ``` When ran locally through a shell, it should report the name of the current user. However, when ran through FileWave, it should report the System name. Prior to FileWave 15.5, the Windows client was 32bit, but since then, a 64bit client is supplied. Either way, the user executing any scripts is the System user. As such, all tests should be ran in that same context:| Version | User | Bit |
| FileWave 15.5+ | System | 64 |
| FileWave 15.4.x- | System | 32 |
Fileset Properties has the option to specify 32 or 64bit, setting the executing environment.
Although FileWave 15.5.0 now provides 64bit options by default, current scripts will automatically be set as 32bit
Custom Fields and Blocker Scripts in 15.5.0 are still currently 32bit only. This should be addressed in an upcoming release.
PsTools: This relies on downloading and installing, onto the test machine, [PsTools](https://docs.microsoft.com/en-us/sysinternals/downloads/pstools).
#### Running Environment ##### Prior to FileWave 15.5 Take a look at [Getting a CMD prompt as SYSTEM in Windows Vista and Windows Server 2008](https://blogs.technet.microsoft.com/askds/2008/10/22/getting-a-cmd-prompt-as-system-in-windows-vista-and-windows-server-2008/) for details about running scripts as System. Note, that by default, this will start an executable as 64-bit, for native 64-bit OS. From a device with the PsTools installed, start by opening a Command Shell as an Administrator. From that shell, another command should be run to open yet another shell, but this time in the chosen environment. The below example shows launching the 32bit version of PowerShell as the System user: ```powershell PSEXEC -i -s -d C:\Windows\SysWOW64\windowsPowerShell\v1.0\powershell.exe ``` To open a command shell in that same environment would use the following: ```powershell PSEXEC -i -s -d %windir%\SysWoW64\cmd.exe ``` Similarly, when attempting to run some commands, it may be necessary to ensure Windows is using the correct version of a binary with the '[sysnative](https://docs.microsoft.com/en-us/windows/desktop/winprog64/file-system-redirector)' redirect. An example would be Bitlocker's 'manage-bde.exe'. To use this in a Fileset, try the following: ```powershell C:\Windows\sysnative\manage-bde.exe -status ``` If you have a requirement to run a particular command through the 64-bit version of Powershell this can be achieved as follows: ```powershell If ( [IntPtr]::Size * 8 -ne 64 ) { C:\Windows\SysNative\WindowsPowerShell\v1.0\PowerShell.exe -File $MyInvocation.MyCommand.Path } Else { # Add code here } ``` Testing scripts designed to be ran with the 64bit FileWave Client, still requires the above actions, to ensure that the System account has been targeted, but this time with a 64bit application. Opening a 64bit version of PowerShell as the System user: ``` PSEXEC -i -s -d C:\Windows\System32\windowsPowerShell\v1.0\powershell.exe ``` #### Example 32bit to 64bit The below demonstrates running a 64bit script, but from the 32bit FileWave Client, which will create a new administrator. Additionally, the FileSet > Get Info > Environment Variables are being used to supply the name and password to the script. Two Fileset Environment Variables are being supplied, for the user 'rstephens' with a password of 'filewave'| Variable | Value |
| username | rstephens |
| password | filewave |
| User Account | Root Account | FileWave Client |
| ``` % echo $PATH | tr ":" "\n" /opt/homebrew/bin /opt/homebrew/sbin /var/root/.cask/bin /usr/local/sbin /usr/bin /bin /usr/sbin /sbin ``` | ``` % echo $PATH | tr ":" "\n" /usr/local/bin /System/Cryptexes/App/usr/bin /usr/bin /bin /usr/sbin /sbin /Applications/VMware Fusion.app/Contents/Public /Library/Apple/usr/bin /var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin /var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin /var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin ``` | ``` /usr/bin /bin /usr/sbin /sbin ``` |