カテゴリー: Windows

ひと目でわかるActive Directory　Windows Server 2022版 / Inc. Yokota Lab

Posted 2023年8月5日 by moleking

定番書として評価の高い「ひと目でわかるActive Directory」シリーズに、待望のWindows Server 2022版が登場です！　Active Directoryの概念および導入、構成管理方法を、詳細な手順と豊富な画面を使ってわかりやすく解説します。
　Active Directoryは、ドメインサービス（DS）、ライトウェイトディレクトリサービス（LDS）、証明書サービス（CS）、Rights Managementサービス（RMS）、フェデレーションサービス（FS）の5つのサービス群の総称です。本書では、ドメインサービスを中心に解説し、その他のサービスについても概要を紹介します。
　Active Directoryを初めて使う方でも、画面を見ながら手順に従って操作するだけで簡単に目的の作業を行うことができます。ある程度使い慣れている方には、Active Directoryをより使いこなすためのリファレンスとしてお使いいただけます。

kindle版を￥3,267で購入した模様。
久しぶりにActiveDirectoryを触ろうと思い、Windows Server2022の試用版を落としてきて、DSとLDS辺りを試した。

それ以降の機能に関しては読んだだけ(ﾉ∀`)ﾀﾒｼﾖｳｶﾞﾅｶｯﾀﾝﾔ
まあ基本的な部分に関しての変更はあんまりないような印象。当たり前か。

よくある概念説明+詳細操作という構成。
可もなく不可もなく。

入れるヒントが少なかったのか"サーバーマネージャーが表示されない場合には"というヒントがヘビローテーションで存在してて、「無理して入れなくてもいいじゃん…(´･ω･｀)」という残念な気持ちにさせられた。つーか目障りだったｗ

この本の後にAzure ADの本をちょっと読んで試そうとしたが、ADテナントの取得辺りでやめた(ﾉ∀`)

Web絡みで面倒くさくなったのとやってて飽きたからｗ

Azure ADとWindows ServerのADは機能や使用目的が違うということだけ知っているだけでいいだろう。

多分、この先、AzureADを触るような仕事に就くことはないだろうし。正直それ程興味がわかなかった。

コンテキストメニューの”編集”からストアアプリ版Paint.Netを開く

Posted 2022年5月5日 by moleking

<あらすじ>
前回(一年半ほど前)、ストアアプリ版Paint.Netに複数画像を"送る"で、ストアアプリ版のPaint.Netで選択した複数画像を開く方法を確立し、自らを天才かと錯覚し歓喜していた俺氏だったが、日に日にその操作量に不満を募らせていた…

(　゜σ･ﾟ）ﾎｼﾞﾎｼﾞ｡oO(コンテキストメニューから[送る]-[ToPaintDotNET.cmd]を選択するのってめんどくせぇな…)

というわけでなんか作業量を減らす方法を調べてみる。

面倒くさいから結論から書くが、レジストリエディタ開いて、
[HKEY_CLASSES_ROOT\SystemFileAssociations\image\shell\edit\command]の値というかデータで指定されている実行プログラム("%systemroot%\system32\mspaint.exe")の部分を、どっかに置いた"ToPaintDotNET.cmd"のフルパスにすれば良いだけだった。

具体的には[ 『"C:\Users\username\AppData\Roaming\Microsoft\Windows\SendTo\ToPaintDotNET.cmd" "%1"』という感じにする。面倒くさいのでSendToに置いてあるのをそのまま指定した(ﾉ∀`)

※ちなみにパスを直書きではなく
『"%APPDATA%\Roaming\Microsoft\Windows\SendTo\ToPaintDotNET.cmd" "%1"』とすると下記の確認というか選択ダイアログが出てきて、うざいことこの上なくなるので注意が必要である(ヽ'ω`)ﾅｾﾞｶﾊｼﾗﾝ

ストアアプリの実体exeらしきものの場所は調べてわかったけれど、単純にそれを指定しても権限だかなんかで実行出来なかったので、前回同様にbatをはさんだ。もっと良い方法があるのかもしれないが、まあこの方法でも複数画像を開けるので、これはこれで良しとする(｀・ω・´)

本当はコンソールウィンドウの表示も抑制したいけど、VBSとかで起動しないと駄目そうだからやめとこうｗ

Windows11でWSLを入れた。

Posted 2021年11月11日 by moleking

Windows11のインストール

インストール中にTPMチェックをレジストリで無効にすれば古いマシンにでもWindows11がインストール出来ると知り、無謀にもdynabook R732/Fという第3世代Core i5マシンへの導入を試みる(｀・ω・´)

あれ(´･ω･｀)？

特に何もせずにインストール出来た？
もしかするとWindows Insider Programに参加していたからかな？
まあよくわからないが普通にインストール出来て動いたわｗ
結局のところ、元々はただの21H2かなんかだもんな。

ちなみにいつも通り、一回目のWindows Update後に起動しなくなった…(ヽ'ω`)
再インストールして数日間経ってから累積更新プログラムを当てたら、特に問題なく起動するようになった。

内容が修正されたのか、うちのマシンの問題なのか知らないが、これはうちのR732/Fではよくあることなので、余り気にしない(ﾉ∀`)

WSLのインストール

故あってWordPressのページ等を触る必要が生じたので、仮想環境を入れることにしたが、VMWareもVirtualBoxも改めて入れるのは面倒くさいなと思い、WSLの利用を思い立つ。

WSLは仮想環境じゃないけど、WordPressの挙動等を確かめるだけなら、別に問題はないしな(｀・ω・´)

なんて甘く考えていたけど、なんか色々と紆余曲折があった。
きっちりとエントリ化するのは面倒くさいのでダイジェストの覚書で。

結論から言うと、WSL のインストールにある通り、

wsl --install

でインストール出来たのだが、そこに至るまでなんかハマった(´･ω･｀)

よくわからないが文字化けする。
Windows PowerShell ISEで実行したのだが、よくわからないエラーが出ているようだった…
いや、もしかするとインストールに成功していたのかもしれないが、メッセージが文字化けしていた為に何がどうなってるかわからなかったｗ
ぐぐって見つけた文字化け回避方法を試すも上手く行かない。
Powershellの実行権限も変えてみても上手く行かない…
よくよく見たら、Powershell用の文字化け回避方法だった(ﾉ∀`)
PowerShell起動時、文字コードをUTF-8に変える方法
 Powershellの文字化けを直す方法

Windows PowerShell ISEは取れる引数も違うようなので、取り敢えずPowershellの方で作業を実行。インストール後に再起動したんだったかな？
インストールに成功し、ユーザーを追加したけれども、なんか通らないコマンドが沢山出てくる(´･ω･｀)？
どうもsystemdがPID1じゃないのが問題らしい。
Windows 10 or 11 Home（WSL2）のUbuntuでsystemctlを利用する方法（systemdをPID1で動作させる方法）
上記のサイトの方法でなんとか無事にSystemdをPIDで起動させることは出来たが、ここでもいくつかつまづいた…(ヽ'ω`)
接続状況が悪かったせいか、一発目の
```
sudo apt install -y daemonize dbus dotnet-runtime-5.0 gawk libc6 libstdc++6 policykit-1 systemd systemd-container
```
ではエラーが出た。
次のdotnet-runtime-5.0のインストール後に上記のコマンドを再度実行したら、上手く行った…ような……
そもそもなんでdotnet-runtime-5.0を2回インストールするんだろうか？

※2回目に試していたらなんかやり方を間違えたのか、dotnet-runtime-5.0がUnable to locate package dotnet-runtime-5.0になってしまった(´･ω･｀)

Ubuntu に .NET SDK または .NET ランタイムをインストールするの20.04のとこのランタイムのインストールのとこの"aspnetcore"を"dotnet"にしたら入ったみたい…
```
sudo apt-get update;
sudo apt-get install -y apt-transport-https &&  sudo apt-get update && sudo apt-get install -y dotnet-runtime-5.0
```
wsl-transdebianのリポジトリ設定でまたまたはまる(´･ω･｀)
毎回調べて、毎回忘れるヒアドキュメントちゃん(´･ω･｀)
まあこれ自体が問題ではなかった。
知ると便利なヒアドキュメント
まあ、見たらわかると思うんですが sudo の効果はリダイレクトまでは有効にならないご様子

sudoしてもリダイレクトで権限のないファイルに書き込めない時の対処法
ということらしいので、
```
sudo -s
```
してからコマンド実行したら上手く行った。
その後も再起動してなくて、なんか変な感じになったりしたけれども、再起動したりして続けたら何とか上手く行って、ubuntuでのコマンドでも不具合がなくなった。

リンク先の途中に出てくるlsb_releaseはディストリビューションのバージョン確認コマンドか。
Ubuntu Version確認からディストリビューションのメモ

まあなんやかんやでWSLをインストールしてubuntuが使えるようになった模様(・∀・)

尚、WordPressを入れて、テーマを変えて、それに付随するプラグインを入れたらWordPressが起動しなくなった…(ヽ'ω`)

wp-config.phpでデバッグをONにしようとしたら文字化け状態…(ヽ'ω`)
単純にデバッグをONにするだけでいいのだけれども一応ぐぐる。

取り敢えず治った(｀・ω・´)
【WSL2】Ubuntu 20.04 で日本語を表示したい

WordPressとプラグインを入れてなんかおかしくなったので、WSLを再インストールしてやり直した…(ヽ'ω`)

やっぱり仮想環境でやったほうがええんかな…

覚え書き: バッチファイル

Posted 2020年12月6日 by moleking

以下は本当はがっつりバッチファイルについて調べてエントリ化しようと思ったが、途中で目的を達成してしまったが為にただの残骸となってしまった文章である(ﾉ∀`)

Windowsにおけるバッチファイルとは

バッチファイル(バッチプログラム/スクリプト)

型式が決まっている繰り返し作業等の一連の処理をWindows上で自動的に実行バッチ処理する為の手順をWindowsコマンドで記述したテキストファイル。

時代背景等、より詳しい内容は以下を参照。
batchが指すものは何か？　IT業界独自の概念「一般化」を理解しよう

batch
(パン・陶器などの)ひとかまど、ひと焼き分、1 度分、ひと束、一群、一団
script
(演劇・映画・ラジオ放送などの)台本、脚本、スクリプト、手書き、筆跡、筆記体(活字)、スクリプト体、文字、答案

拡張子の違い (bat or cmd)

拡張子にはbat,cmdが用いられる。

bat拡張子はDOS時代から使い続けられていて、cmd拡張子は32ビットOSのNT系以降で使用され始めた模様。

cmd拡張子は非NT系環境でそのスクリプトが実行されないようにする為に明示的にbatと使い分けがされていたようだが、今は非NT系のWindowsやDOS環境はほぼほぼ姿を消しており、また依然としてbat拡張子を使い続ける風潮があった為か、現在では基本的にどちらでも良いようである。

実行可能ファイルの拡張子を指定する環境変数「PATHEXT」には
".COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC"
といった順で記載されているので、Microsoft的には特にbat拡張子を使わずにcmd拡張子を使えと強制はせず、もしも使い分けたいのであれば、ユーザー側で考えて選択しろということなのだろうか。

尚、細かな違いとして、ERRORLEVELが"0"でない状態で、"PATH/APPEND/PROMPT/SET/ASSOC"等を実行した場合、batだとERRORLEVELに以前の非"0"の値が残り、cmdでは"0"にリセットされるらしい。

例えば下記の内容を拡張子を変えて実行すると、

@echo off
type
PATH
echo %errorlevel%

以下のような結果になる。(typeコマンドがエラー 1を返すが結果が異なる。)

Windows batch files: .bat vs .cmd?

コマンドシェルとは

(コマンドラインシェル/コマンドラインプロセッサ/コマンドラインインタプリタ)

本義としてはユーザーがOSに命令・利用するためのユーザーインターフェイスを提供するプログラムであるが、バッチ処理という観点から見た場合、バッチファイル内の命令群を逐次解釈し、処理を行う実行エンジンと考えても差し支えはないと思われる。

NT系ではcmd.exeがデフォルトのコマンドシェルである。(それ以前はcommand.com)
このコマンドシェルの指定は環境変数「ComSpec」の値で決定される。
※Windows10でのデフォルト値は"%SystemRoot%system32cmd.exe"となっていた。

現行のWindows10では従来型のコマンドシェルとこれを拡張したPowerShellを利用できる。

PowerShellではWindowsコマンドの他により多くの処理が可能なPowerShellコマンドレットを実行できる。
具体的には.NET Frameworkのクラスを利用できる。

Windows のコマンド

この他にスクリプト実行環境としてWindows Scripting Host(WSH)がある。
こちらはVBScriptやJScriptで記述し、WMIを始めとするCOMオブジェクトを利用できる。

WSH環境は上記のコマンドシェルと異なり、ファイルとして存在するスクリプトを実行する。

つまり上記のコマンドシェルのようなユーザーインターフェイス的部分がない単純な実行エンジンと言える。
バッチファイルすらまだまだ現役なので、当然ながらWSHもまだまだ現役である模様。

色々調べてて思ったけど、もう今更バッチファイルについて勉強するならWSHやPowerShellの勉強をしたほうがいいなってちょっと思った(ﾉ∀`)