windows

TL;DR MacBook Air Mid 2013でbootcamp上でWindows 10を動かしてそれなりに動作させるのには、以下の作業が必要でした。 Windows 10 21H1のISOでBootcampをセットアップ コンピューターが予期せず再起動されたか...とエラーが表示されてセットアップが進まなくなるので、Shift+F10キーを押してコマンドプロンプトを起動し、regeditを起動してHKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\ChildCompletionのsetup.exeの値を1から3に変更 この時点でNICが未認識 Mac側のBootcampアシスタントで[アクション]-[Windowsサポートソフトウェアをダウンロード]より一式ダウンロードしてUSBメモリに保存 Windows側でUSBメモリ内のSetup.exeを実行 この時点で英数、かなキーを認識できず日本語切り替えがうまくいかない デバイスマネージャーでApple Keyboardをアンインストール。ドライバーのソフトウェアも削除 この時点で英語キーボードと認識され、記号の入力がキーボードの印字通りにならない Windowsの[設定]-[時刻と言語]-[言語]の[優先する言語]にある「日本語」をクリックして[オプション]をクリック。ハードウェアキーボードレイアウトを「英語キーボード(101/102キー)」から「日本語キーボード(106/109キー)に変更 経緯 奥さんが利用しているMac Book Air(Mid 2013)が128GBで、容量不足で作業が滞るため、余っていた1TB SSDに交換しました。 が、このモデル、現時点ではサポート終了で最新バージョンにアップグレードできない… 最新のMac買えばと薦めたのですが、最近ほとんど使わないので要らないとのこと。もったいないのでBootcampでWindows 10を入れて2025年までは延命させようと作業しました。 このモデルではHigh Sierraまでしかサポートされていません。この状態でBootcampアシスタントでWindows 10 21H1のISOを利用してBootcampを実行すると、途中ハードウェアの認識エラーにより先に進まなくなります。 https://asterisk-works.com/how-to-install-boot-camp-on-macbook-nvme-ssd/ を参考にレジストリ値を変更することでとりあえずエラーは回避。ですがこの状態だとドライバがまともに入っていないようで、NIC未認識によりアップデートもできない状態。 Mac側でBootcampアシスタントで[アクション]-[Windowsサポートソフトウェアをダウンロード]より一式ダウンロードしてWindowsで認識できるFATフォーマットのUSBメモリに保存。3GB弱ありました。で、Windows側でSetup.exeを実行し、再起動させてNICをはじめ各種HWは認識されました。 日本語変換がうまくいきません。IMEの設定で無変換キー、ひらがなキーにIME-OFF/ONの設定をしてもダメ。インストールされたキーボードドライバではキーの認識がうまくいっていないようでした。そこでデバイスマネージャーでApple Keyboradをアンインストール、ドライバーソフトウェアの削除のチェックボックスも入れて再起動すると、認識するようになりました。 https://i-tsunagu.com/mac/keyboard-notrecognize/ が、記号類の認識がおかしい。「@」を入力しようとするとShift+2を実行する必要がある状態。英語キーボードとして認識されているようなので、Windowsの[設定]-[時刻と言語]-[言語]の[優先する言語]にある「日本語」をクリックして[オプション]をクリック。ハードウェアキーボードレイアウトを「英語キーボード(101/102キー)」から「日本語キーボード(106/109キー)に変更してキーボードの印字通りに入力できるようになりました。 いろんなサイトを調べながら結構大変な作業でした。これは素人では無理。最新でないHigh Sierraで実行したこともあるのかもしれませんが、Bootcampアシスタントというお手軽そうなツールがあるからと気軽に手を出すと痛い目を見るな(自分含め)と思いました。

TL;DR Windowsをファイルサーバ等の目的でフォルダを共有する際は、共有アクセス権を「フルコントロール」にはせず、「変更」+「読取」にする。 「フルコントロール」にすると、作成したファイル、フォルダに対して権限の変更が可能になってしまう。 経緯 Windowsをファイルサーバ等の目的でフォルダを共有する際、共有フォルダ権限とNTFS権限の2つがあり、どのように設定するか迷うことも多いです。 NTFS権限のほうが細かく設定できるため、共有アクセス権限は「フルコントロール」にしてNTFS権限で制限すればよいとしているサイトを多く見かけます。当社もそのように設定していました。 ですが、このように設定すると、利用者が作成したファイルやフォルダに対して利用者自身がアクセス権の変更を行うことができてしまいます。作成したファイル・フォルダの「所有者」は利用者が設定されてしまうためです。 対応としては、NTFS権限はそのままで共有アクセス権限を「変更」+「読み取り」に変更すればよいです。

TL;DR WindowsでHDDからSSD換装などでシステムディスクを入れ替える際は コピー先のディスク容量(パーティションサイズではなく)がコピー元より大きい場合: Windows標準のイメージバックアップからシステム修復ディスクによる復旧でOK コピー先のディスク容量(パーティションサイズではなく)がコピー元より小さい場合: 素直に有償のクローンソフトを使おう 経緯 HDDで動作しているWindows 10をSSDに入れ替える作業を行いました。この手の作業でベストなのは、　HDDで必要なデータをバックアップしておき、　SSD側ではWindowsをクリーンインストールしてバックアップからデータを復旧、必要なプログラムは再度インストールしてもらうことです。 ですが、インストール済みのソフトを再インストールする手段がない、バックアップで必要な設定が復旧できるかわからない、等の理由でできないことがあります。今回もそうでした。 Windows 10にはイメージバックアップを取る機能がありますが、復旧時に同じサイズのパーティションを作成します。コピー先のディスクサイズがコピー元より大きければ問題ないのですが、そうでないと一筋縄では行きません。今回、以下の作業を行いましたが、問題を解消できませんでした。 Windowsで使用しているドライブ(今回はCドライブのみ)を「ディスクの管理」でサイズを縮小し、コピー先より小さいサイズにした ディスクの最後尾に設定されていた回復ドライブを削除し、縮小したCドライブのパーティション以降はすべて空き領域とした 回復ドライブを削除すると、イメージバックアップからの復旧に必要となるシステム修復ディスクが作成できなくなるうことがあるので、事前に作成しておく 一旦再起動し、イメージバックアップを取得、復旧を試みた。 有償ソフトの存在はもちろん知っていましたが、なんとかお金をかけずにといろいろ行い、ディスクの読み書きを伴う作業なのでとにかく時間がかかってしまいました。が、数千円の有償ソフト使ってあっという間に解消しました。 自分の作業の時間単価を冷静に考えないとだめですね。

http://tack41tu.hatenablog.com/entry/2018/07/30/214927 でClickOnceアプリをインストールする際にレジストリを編集する必要がある事を書いた。 レジストリエディタで編集するのは面倒だし運用も大変なので、レジストリを編集するアプリを作成した。 https://msdn.microsoft.com/en-us/library/ee308453.aspx にある以下のコードを書いて実行し、正常終了するのだがレジストリエディタで確認すると変更が反映されておらず、ClickOnceの動作も変わらない。 Microsoft.Win32.RegistryKey key; key = Microsoft.Win32.Registry.LocalMachine.CreateSubKey("SOFTWARE\\MICROSOFT\\.NETFramework\\Security\\TrustManager\\PromptingLevel"); key.SetValue("LocalIntranet", "Enabled"); key.Close(); どうもレジストリは32bit, 64bitで別の領域らしく、プログラム作成時にターゲットCPUをAnyとし、x86優先とした結果、32bitの領域を更新してしまっているらしい。 https://aonasuzutsuki.hatenablog.jp/entry/2015/12/08/173819 を参考に以下のように記載したところ、想定通りに動作するようになった。 Microsoft.Win32.RegistryKey key_base, key; key_base = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64); var key = prerKey.CreateSubKey("SOFTWARE\\MICROSOFT\\.NETFramework\\Security\\TrustManager\\PromptingLevel",); key.SetValue("LocalIntranet", "Enabled"); key.Close();

社内情シスには常について回る、ファイルサーバーアクセスできない問題。 私も過去何度も経験しているし、WINS, SMBなどの知識もあるのでそんなに悩むことはここのところありませんでした。 しかし、今回は様子が異なり、以下のような症状。 \\SVRNAME でアクセスできない。 \\SVRNAME.domain.name のようなFQDNでもダメ 他のサーバに対しての\\SVRNAME2 のアクセスは可能。ダメなのは1台のサーバのみ(?) ping SVRNAME は通る(!?) \\IPアドレス であれば該当のサーバでもアクセスできる NetBIOS over TCP/IPは有効になっている %WINDIR%\system32\drivers\etc にあるhosts, lmhosts にエントリはない 上から見ていって、1,2番目まではよくあるNetBIOSの名前解決エラーかと思ったのだが、3,4番目あたりからどうも様子が違う… 結果は、Windowsのコンパネ-[ユーザーアカウント]-[資格情報マネージャ]に、サーバー名で認証情報が登録されており、指定されたアカウントが無効となっていたため。 こんなところで指定しなくてもADログインすれば自動で認証するので、登録情報を削除したところアクセス可能となった。 Windows は奥が深い #いい意味ではない