カテゴリー: Windows

投稿日:

ASUS VivoBook E203NAにWindows10とChromeOSを入れた

秋葉原のMLcomputerにいったら整理中の箱の中にASUSの薄いノートが入っていた。

電源ボタンおしてみたけど、電源は入らない、という状態だったけど、「これいくら？」と聞いて見た。

すると、「ASUS E203MA(あとで調べたらCPUがN4000とちょっとスペックが上)でキーボードが使えないジャンク品を3千円としている」ということだったので、３千円で購入した。

裏面みるとネジが１つなく、１つがセロテープで無理矢理とめられていた。

んー、と思いつつ電源ON

F2キーでBIOS/UEFI画面に入ることができた。

スペックを確認するとASUS VivoBook E203NA の下位モデルでCPU N3350、RAM 2GB、eMMC 32GBというものだった。

メインストレージが64GB未満なのは現状Windows10で使うにはキツイものでした。

Windows 10 21H1をインストールして一通りWindows Updateをかけるとデバイスは全て正常に認識しましたが、問題が・・・

そう、OSだけでほぼ全て使ってしまうのです。

あと、注意点として、Windows 10インストール直後のQualcomm Atheros QCA9377ドライバだとバッファローWSR-1800AX4の802.11ax Wi-Fi EasyMesh対応版に接続出来ないという不具合が・・・

Windows Updateを行って下記のv12.0.0.919にアップデートすると接続出来るようになります。

このほかWebブラウザでサイトを見たりしていたら空き容量が2GBを切っているという・・・

裏面のネジがおかしいのもあるので中を確認

増設の余地は全くない構造でした。

基板がどうなっているかは下記の動画をみてもらうと良さそうです。

なお、ネジがちゃんとついていなかったのは、ネジの長さが２種類あって、２本だけ長いものがあるんですが、その２本の使いどころを誤っていたせいでした。

正しくは下記の画像の赤丸の２箇所なんですが、分解した人は下側左右両サイドに使っていました。

さて、ストレージ増設なんてことはできそうにないので、ChromeOS+brunchで起動してみます。

まずはBIOSでSecurebootをdisableにかえてから、Boot ManagerからUSBメモリを選択して起動します。(電源ON後にいきなりBoot Managerを出す手法は分からなかった)

ChromeOSリカバリイメージはrammus、grubで設定するoptionsは「options=enable_updates,pwa」だけでいけるというなかなか素直な状態でした。

Ctrl+Alt+Tからshellを開いて「sudo chromeos-install -dst /dev/mmcblk0」で内蔵ストレージにChromeOSを書き込んで、本体のみでのChromeOS起動を確認しました。

興味深かったのは、いままでbrunchでrammusイメージを元にしてChrome OSで起動したノートパソコンでGoogleアカウントログインを行うと「お使いの Chome OSで～」というメールが来てたのですが、ASUS VivoBook E203NAにChromeOSを入れたやつでは「お使いの ASUS Chromebook Flip C434で～」と、機種名が書かれたメールになっていた。

ベースとしているrammusは「ASUS Chromebook C425, ASUS Chromebook Flip C433, ASUS Chromebook Flip C434」向けイメージなので、わからなくもないんですが

ASUS Chromebook Flip C434 はCore m3-8100Y/RAM 4GB/ストレージ 32GB/14.0インチ1920*1080/タッチパネルあり、とだいぶスペックが違うのになぁ・・・といった感じです。

2022/05/06追記

Google純正となった「Chrome OS Flex」をASUS VivoBook E203NA上で試したところ、特に問題なく動作しました。

2022/07/20追記

ChromeOS Flexの正式版を入れてみましたが、引き続き特に問題無く動作しました。

入れ替え前は５月にインストールしたベータ版時代のものでしたが、そのときは「104.0.5087.0 (Official Build) dev (64ビット)」という状態で、チャンネルが固定となっており、devからstableへの移行ができませんでした。

正式版に入れ直したところ103.0.5060.114 とdev無しのバージョンとなりました。

投稿日:

古いONTAPがActive Directoryに参加できない

古いONTAP、具体的にはONTAP 8.3.2環境の移行案件があったので、検証のためにONTAP simulatorのONTAP 8.3.2版を仮想環境上に作成して、Active Directoryに参加しようとしたところ下記のエラーとなった。（なお、接続先Active Direcrotyはsamba 4.14.5で構成している)

ontap832::> vserver cifs create -cifs-server share226 -domain adosakana.local -vserver share226

In order to create an Active Directory machine account for the CIFS server, you
must supply the name and password of a Windows account with sufficient
privileges to add computers to the "CN=Computers" container within the
ADOSAKANA.LOCAL domain.

Enter the user name: administrator

Enter the password:

Error: Machine account creation procedure failed
  [ 12154] Loaded the preliminary configuration.
  [ 12332] Created a machine account in the domain
  [ 12339] Successfully connected to 172.17.44.49:445 using TCP
  [ 12351] Unable to connect to LSA service on
           samba.adosakana.local (Error:
           RESULT_ERROR_GENERAL_FAILURE)
  [ 14357] TCP connection to 172.17.44.141:445 via interface
           172.17.44.236 failed: (Operation timed out).
  [ 14357] Could not open a socket to 'samba.adosakana.local'
  [ 14357] Unable to connect to LSA service on
           samba.adosakana.local (Error:
           RESULT_ERROR_SPINCLIENT_UNABLE_TO_RESOLVE_SERVER)
  [ 14357] No servers available for MS_LSA, vserver: 2, domain:
           adosakana.local.
**[ 14357] FAILURE: Unable to make a connection (LSA:adosakana.local),
**         result: 6940
  [ 14357] Could not find Windows SID
           'S-1-5-21-937304154-1581684492-536532533-512'
  [ 14381] Deleted existing account
           'CN=SHARE226,CN=Computers,DC=adosakana,DC=local'

Error: command failed: Failed to create the Active Directory machine account
       "SHARE226". Reason: SecD Error: no server available.

ontap832::>

これは暗号化の問題なので「vserver cifs security show」で設定項目を確認する。

ontap832::> vserver cifs security show -vserver share226

Vserver: share226

                    Kerberos Clock Skew:                   - minutes
                    Kerberos Ticket Age:                   - hours
                   Kerberos Renewal Age:                   - days
                   Kerberos KDC Timeout:                   - seconds
                    Is Signing Required:                   -
        Is Password Complexity Required:                   -
   Use start_tls For AD LDAP connection:               false
              Is AES Encryption Enabled:               false
                 LM Compatibility Level:  lm-ntlm-ntlmv2-krb
             Is SMB Encryption Required:                   -

ontap832::>

ONTAP 8.3.2無印では関連するオプション「SMB2 Enabled for DC Connections」を設定する項目が無い

ontap832::> version -node *

ontap832-01:
NetApp Release 8.3.2: Tue Feb 23 23:35:06 UTC 2016


ontap832::>

アップデータを探したところ、832P12_q_image.tgz(リンク先はNetAppサポートサイトにログインを済ませてからアクセス) があったので、「ONTAP 9.7シミュレータをアップデートする手法」と同じ手法でアップデートを行った。

ontap832::> version -node *

ontap832-01:
NetApp Release 8.3.2P12: Mon Aug 14 02:57:01 UTC 2017


ontap832::>

ONTAP 8.3.2P12であれば、「SMB2 Enabled for DC Connections」が存在していた。

ontap832::> vserver cifs security show -vserver share226

Vserver: share226

                    Kerberos Clock Skew:                   - minutes
                    Kerberos Ticket Age:                   - hours
                   Kerberos Renewal Age:                   - days
                   Kerberos KDC Timeout:                   - seconds
                    Is Signing Required:                   -
        Is Password Complexity Required:                   -
   Use start_tls For AD LDAP connection:               false
              Is AES Encryption Enabled:               false
                 LM Compatibility Level:  lm-ntlm-ntlmv2-krb
             Is SMB Encryption Required:                   -
        SMB1 Enabled for DC Connections:                   -
        SMB2 Enabled for DC Connections:                   -

ontap832::>

設定を変更

ontap832::> vserver cifs security modify -vserver share226 -smb1-enabled-for-dc-connections false -smb2-enabled-for-dc-connections true

ontap832::> vserver cifs security show -vserver share226

Vserver: share226

                    Kerberos Clock Skew:                   - minutes
                    Kerberos Ticket Age:                   - hours
                   Kerberos Renewal Age:                   - days
                   Kerberos KDC Timeout:                   - seconds
                    Is Signing Required:                   -
        Is Password Complexity Required:                   -
   Use start_tls For AD LDAP connection:               false
              Is AES Encryption Enabled:               false
                 LM Compatibility Level:  lm-ntlm-ntlmv2-krb
             Is SMB Encryption Required:                   -
        SMB1 Enabled for DC Connections:               false
        SMB2 Enabled for DC Connections:                true

ontap832::>

そして、Active Directoryへの参加

ontap832::> vserver cifs create -cifs-server share226 -domain adosakana.local -vserver share226

In order to create an Active Directory machine account for the CIFS server, you
must supply the name and password of a Windows account with sufficient
privileges to add computers to the "CN=Computers" container within the
ADOSAKANA.LOCAL domain.

Enter the user name: administrator

Enter the password:

Warning: An account by this name already exists in Active Directory at
         CN=SHARE226,CN=Computers,DC=adosakana,DC=local
         Ok to reuse this account? {y|n}: y

ontap832::>

今度は成功した。

投稿日:

Windows 11 Insider Preview環境でWSLg経由で起動したUbuntu 20.04のfirefoxが日本語文字化けする

Windows 11 Insider Previewにした環境で、WSLgを使ったLinux GUIのテストをしてみようと、Ubuntu 20.04を設定して、firefoxを起動してみた。(別途 sudo apt install firefox でインストール済み)

まぁ、文字化けした。

どうせ、いつもの(Zentyalを日本語で使う場合の設定手順)だろう、と「sudo apt install fonts-arphic-uming fonts-takao-gothic」でフォントをインストールして

firefoxを起動したところ、問題なく表示されました。

投稿日:

ESXiのみ環境でPowerCLIを使ってテンプレートもどきの動作をする手法

vCenterサーバがない、ESXiサーバのみ環境ではテンプレート機能が使用できない。

とはいえ、テンプレート化した仮想マシンの中身を見ると、ふつうと同じく仮想ハードディスクのvmdkファイルが存在しているので、vmdkファイルをコピーして、新規仮想マシンを作成するPowerCLIスクリプトをかけば、似たようなことができるな、と実験。

準備するもの

・PowerCLIをインストールした環境
Windows 10で実行したが、Linux環境にPowerShell+PowerCLIをセットアップしてもいけるはず。

・Windowsの場合、sysprepを実行してシャットダウンしたvmdkファイル
sysprepを実行して、次回起動時に初期セットアップが開始されるようにしたvmdkファイル。
VMware-toolsはインストール済みであることが望ましい。

・Linuxの場合、下記の情報などを削除
RHEL7の仮想化の導入および管理ガイド第4章 仮想マシンのクローン作成によれば
/etc/udev/rules.d/70-persistent-net.rules を削除
/etc/ssh/ssh_host_* を削除
/etc/sysconfig/network-scripts/ifcfg-eth* などから IPADDRESS,NETMASK,HWADDRなどの値削除

スクリプト本体

Import-Module VMware.VimAutomation.Core

#Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false

$vcenterserver="ESXiサーバ"
$vcenteruser="ユーザ名"
$vcenterpassword="パスワード"

$targetdatastore="仮想マシンをおくデータストア名"

# 仮想マシンの名前 / ランダムで作成して、あとから変更する手法
$vmnamebase="NewVM_"
$vmnametmp=Get-Random
$vmname=$vmnamebase+$vmnametmp

# 仮想マシンスペックと接続ネットワーク指定
$vcpu=2
$vmem=6
$network="VM Network"

# 指定できるGuestOSのIDを調べるには下記を実行すること
#   PowerCLIがサポートしている一覧 
#   [VMware.Vim.VirtualMachineGuestOsIdentifier].GetEnumValues()
# 代表的なもの
# windows8Server64Guest = Windows2012
# windows9Server64Guest = Windows2016
#$vmguestosid="windows9Server64Guest"

# 元ネタのWindowsが入ったvmdkファイルの指定
# 構築時にBIOS環境かEFI環境のどちらで作ったのか注意
$vmdkfilepath="[データストア名] windows2019/windows2019.vmdk"
$vmguestosid="windows9Server64Guest"
#$vmdkfilepath="[データストア名] win2016/win2016.vmdk"
#$vmguestosid="windows9Server64Guest"
#$vmdkfilepath="[データストア名] win2012/win2012.vmdk"
#$vmguestosid="windows8Server64Guest"
# 上記の元ネタが置いてあるデータストア名を下記でも指定する
$sourcedatastore ="データストア名"

# vCenterまたはESXiサーバに接続
Connect-VIServer -Server $vcenterserver -User $vcenteruser -Password $vcenterpassword -WarningAction 0
# パスワードを書きたくない場合は
# New-VICredentialStoreItem -Host $vcenterserver -User $vcenteruser -Password $vcenterpassword
# を実行すると、資格情報保存域に登録され、以降は下記だけで接続できるようになる
# Connect-VIServer -Server $vcenterserver

$virtualportgroup=Get-VirtualPortGroup -Name $network
$datastore=Get-Datastore -Name $targetdatastore
$vm=New-VM -Name $vmname -NumCpu $vcpu -MemoryGB $vmem -Portgroup $virtualportgroup -Datastore $datastore -DiskStorageFormat Thin -GuestID $vmguestosid -HardwareVersion vmx-14


$olddiskinfo=Get-Vm $vmname|Get-Harddisk # 一時的に作られたディスクの情報を保存
$sourcevmdk=Get-HardDisk -Datastore $sourcedatastore -DatastorePath $vmdkfilepath
# ディスクの削除
Remove-HardDisk -HardDisk $olddiskinfo -Confirm:$false


# コピー先データストアのパスを生成
$targetvmdktmp=$olddiskinfo.Filename
$ed=$targetvmdktmp.LastIndexOf("/")
$targetvmdk=$targetvmdktmp.Substring(0,$ed+1) # コピー先のパス

# OSが入ったvmdkのコピー
$adddiskinfo=Copy-HardDisk -Harddisk $sourcevmdk -DestinationPath $targetvmdk -DestinationStorageFormat Thin

#$vm = get-Vm $vmname
New-HardDisk -VM $vm -DiskPath $adddiskinfo.Filename

Get-ScsiController -VM $vm | Set-ScsiController -Type VirtualLsiLogicSAS

# 仮想マシン設定変更用オブジェクト定義
$newSpec = New-Object VMware.Vim.VirtualMachineConfigSpec

# USBコントローラの追加
# これがないとWindows環境でマウスが動かない
# https://communities.vmware.com/t5/VMware-PowerCLI-Discussions/Where-is-the-quot-Get-USBController-quot-cmdlet-Same-with-Remove/td-p/2155582
# 上記だとUSB 2.0コントローラ追加
$newSpec.deviceChange = New-Object VMware.Vim.VirtualDeviceConfigSpec[] (1)
$newSpec.deviceChange[0] = New-Object VMware.Vim.VirtualDeviceConfigSpec
$newSpec.deviceChange[0].operation = "add"
#$newSpec.deviceChange[0].device = New-Object VMware.Vim.VirtualUSBController # USB2.0コントローラ
$newSpec.deviceChange[0].device = New-Object VMware.Vim.VirtualUSBXHCIController # USB3.0コントローラ

# EFIかBIOSか
# https://docs.vmware.com/jp/VMware-Cloud-on-AWS/services/com.vmware.vsphere.vmc-aws-manage-vms.doc/GUID-898217D4-689D-4EB5-866C-888353FE241C.html
#https://github.com/vmware/PowerCLI-Example-Scripts/blob/master/Scripts/SecureBoot.ps1
# BIOSを設定する場合は、SecureBootをdisableにする必要がある
#$newSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
# 仮想マシン起動オプション変更用オブジェクト定義
$bootOptions = New-Object VMware.Vim.VirtualMachineBootOptions
#$newSpec.Firmware = [VMware.Vim.GuestOsDescriptorFirmwareType]::efi
#$bootOptions.EfiSecureBootEnabled = $true
$newSpec.Firmware = [VMware.Vim.GuestOsDescriptorFirmwareType]::bios
$bootOptions.EfiSecureBootEnabled = $false
$newSpec.BootOptions=$bootOptions


# 仮想マシンへの設定反映
#(get-view $vm).ReconfigVM_Task($newSpec)
$vm.ExtensionData.ReconfigVM($newSpec)


# 接続切断
Disconnect-VIServer -Server $vcenterserver -Confirm:$false

解説

仮想マシンにハードディスクを追加する

仮想マシンに新しく空っぽのハードディスクを追加する場合は、「New-HardDisk -VM 仮想マシン ～」で指定するが、Copy-HardDiskでコピーしてきたハードディスクを登録する場合が分かりづらかった。

結果としては、新規と同じく「New-HardDisk -VM 仮想マシン ～」でよかった。

今回の場合は、CopyHardDiskを実行した結果を変数にいれて、それをNew-HardDIskで登録、という形にした。

$adddiskinfo=Copy-HardDisk -Harddisk $sourcevmdk -DestinationPath $targetvmdk -DestinationStorageFormat Thin

$vm = get-Vm $vmname
New-HardDisk -VM $vm -DiskPath $adddiskinfo.Filename

仮想マシンハードウェアにUSB 3.0コントローラを追加する

Host Clientから作成した場合は、USB 3.0コントローラが作成されていたが、New-VMコマンドでは作成されなかった。このため、Windowsが起動した後にUSBマウスが存在できず、マウス操作ができなかった。（キーボードはPS/2キーボード扱いとして使えたようだった）

このUSB 3.0コントローラを追加するための操作がわからず、いろいろ調べたところ「Where is the “Get-USBController” cmdlet? (Same with Remove- and New-)」の記述を見て、USB 2.0コントローラの追加手法が分かった。

その後、VirtualUSBController を起点に調べることで、 xHCIはVirtualUSBXHCIControllerという名前であることがわかり、解決した

$vm=Get-VM -Name 仮想マシン名
$newSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
$newSpec.deviceChange = New-Object VMware.Vim.VirtualDeviceConfigSpec[] (1)
$newSpec.deviceChange[0] = New-Object VMware.Vim.VirtualDeviceConfigSpec
$newSpec.deviceChange[0].operation = "add"
#$newSpec.deviceChange[0].device = New-Object VMware.Vim.VirtualUSBController # USB2.0コントローラ
$newSpec.deviceChange[0].device = New-Object VMware.Vim.VirtualUSBXHCIController # USB3.0コントローラ

# 仮想マシンへの設定反映
#(get-view $vm).ReconfigVM_Task($newSpec)
$vm.ExtensionData.ReconfigVM($newSpec)

設定を反映する部分は、ネタ元では「Get-View」を使っていたが、後述のSecureBootについての結果ではGet-VM経由で実施しているスクリプトがあったので、それを使用している。

BIOS/EFI切り替え

仮想マシンをBIOS起動にするか、EFI起動にするかを設定する手法。

2021現在のPowerCLIでNew-VMした時のデフォルトはEFI起動でセキュアブート有効になっている。

これをBIOS起動に設定する場合は、セキュアブートを無効にしてからBIOSに切り替える必要があるので下記にようになる。

$vm=Get-VM -Name 仮想マシン名
$newSpec = New-Object VMware.Vim.VirtualMachineConfigSpec

$bootOptions = New-Object VMware.Vim.VirtualMachineBootOptions
$bootOptions.EfiSecureBootEnabled = $false
$newSpec.BootOptions=$bootOptions

$newSpec.Firmware = [VMware.Vim.GuestOsDescriptorFirmwareType]::bios

$vm.ExtensionData.ReconfigVM($newSpec)



投稿日:

検証専用Active Directoryに参加しているWindows Server 2019に他のADに参加しているWindowsクライアントからリモートデスクトップ接続ができない

検証専用Active Directoryに参加しているWindows Server 2019に他のADに参加しているWindowsクライアントからリモートデスクトップ接続ができない。

画像
リモート デスクトップ接続
認証エラーが発生しました。
要素が見つかりません。

リモート コンピューター: ～

しかも、このエラー、接続先のWindows Serverのコンソールから該当するActive Directoryユーザでログイン成功してからリモートデスクトップ接続をかけると成功するという状態。
(接続先Windows Serverを再起動するとまたログインできなくなります)

失敗する場合のWindows Server 2019側のイベントログは下記の様に出ている。

画像
イベントID: 4625
失敗の原因: ログオン中にエラーが発生しました。
状態: 0xC0000225
サブステータス: 0x0

Microsoftの「4625(F): An account failed to log on.」で、”0xC0000225″を確認すると「Evidently a bug in Windows and not a risk」(Windowsのバグ)って・・・

困ったことにそれ以上の手がかりがない・・・

いままで試していたのはWindows標準のリモートデスクトップアプリ(mstsc)。

これ以外にもMicrosoftストアに「Microsoft リモート デスクトップ」がある。

こちらで試してみるとログインに成功！

ログイン成功以後は、mstsc でもログインに成功するようになりました。

2022/03/22 追記

関係しているような事例を見かけた

ServerWorks社blog「Windows ServerにRDP接続する際、ユーザにパスワード変更を求めるようにしたくてハマったこと」によれば「Windows Server 2012 R2 および Windows 8.1 以降のネットワーク レベル認証の動作について」にかかれているような形で、リモートデスクトップの際に要求されるネットワークレベル認証にいろいろ差異があるらしい。

2022/04/01追記
↑にあるようにローカルグループポリシーエディッター(gpedit.msc) の[コンピュータの構成]-[管理用テンプレート]-[リモートデスクトップサービス]-[リモートデスクトップセッションホスト]-[セキュリティ]にある２項目を設定することで、ログインできるようになった

なお、OS再起動は必要なかった

「リモート(RDP)接続に特定のセキュリティレイヤーの使用を必要とする」を「有効」にして、「セキュリティレイヤー」を「RDP」で設定

「リモート接続にネットワークレベル認証を使用したユーザー認証を必要とする」を「無効」で設定