Detection of the USB-Serial converter used on your machine (so you get the correct device name to use later):
1. tail -f /var/log/messages or /var/log/syslog
2. Plug in the USB cable
3. It will show up like this:
Nov 19 16:53:12 nyx kernel: [30040.171597] usb 2-1: FTDI USB Serial Device converter now attached to ttyUSB0
Connect with screen as follows:
screen <device> <speed>
root@nyx:~# screen /dev/ttyUSB0 115200
Disconnect with CTRL+a followed by CTRL+d:
[detached from 4197.pts-2.nyx]
Ever deployed a non-English Windows server via SCVMM and then tried installing SQL server on it? Won’t work. The OS and SQL server languages have to match and in a stroke of genius SCVMM always make the base deployment for any new VM templates in English!!
What I’d imagine throws most people off is that the OS will display in the language locale you’d expect – Japanese in my case, but underneath the settings will be English. This can be verified by opening the command prompt. All errors will be in English and not the language the GUI is displayed in.
“SQL Server setup media does not support the language of the OS or does not have ENU localized files. Use the matching language-specific SQL Server media or change the OS locale”
It’s easy enough to fix with an update to the SCMMM VM templates (use the updated template to re-deploy the server OS):
The InputLocale values must match with “ja-JP” or whatever you wish to use. To get the values, please refer to:
Language Pack Default Values: http://technet.microsoft.com/en-us/library/cc766191(v=ws.10).aspx
Default Input Locales: http://technet.microsoft.com/en-us/library/cc766503(v=ws.10).aspx
apt-get install cifs-utils
sudo mount -t cifs //<server>/<share> /<mount point> -o username=<username>,domain=<domain>,password=<your password>
It’s fine to omit the password on the command line for security purposes. It will then prompt for it to be entered and it will remain hidden.
Global settings stored here:
Add to the end:
export HTTP_PROXY HTTPS_PROXY FTP_PROXY http_proxy https_proxy ftp_proxy
Download psexec from Sysinternals / MS. It only needs to be installed on the machine you run the commands from, not the targets.
* All machines must be in the same domain or workgroup
* Firewalls must be down on the targets (haven’t checked exactly which ports, so lowered them for domain access in my case)
* Ideally, create/use a local admin user on each remote machine for execution
Change from DHCP to static IP (note the “-h” for elevated admin access):
psexec \\<remote-computer-name> -u <remote-admin-user> -p <password> -h netsh interface ip set address name=”<interface-name>” static addr=<ip> <mask> <gateway> 1
Since the IP change command doesn’t include DNS settings we also need the the below:
Change DNS settings:
psexec \\<remote-computer-name> -u <user> -p <password> -h netsh interface ip set dns name=”<interface-name>” static addr=<ip>
Example changing the settings remotely on a Japanese Windows 7 machine from a Windows 2012 R2 server:
psexec \\Win7-01 -u admusr -p Passw0rd! -h netsh interface ip set address name=”ローカル エリア接続 2″ static addr=192.168.0.100 255.255.255.0 192.168.0.1 1
psexec \\Win7-01 -u admusr -p Passw0rd! -h netsh interface ip set dns name=”ローカル エリア接続 2″ static addr=18.104.22.168
If you’re uncertain of the interface name: Run “ipconfig” remotely and copy and paste the interface name from there.
psexec \\<remote-computer-name> -u <remote-admin-user> -p <password> ipconfig