Windows Server 2012のActive DirectoryにWindows Server 2022にADとして追加してみた。

この記事を書いていることはそろそろ、Windows Server 2012のお役目御免のタイミングかと思います。

それなのでWindowsServer2022を追加してWindowsServer2012をお休みさせる予定の手順をまとめてみました。

事前準備

・Windows Server 2012のActive Directoryサーバーを用意します。
以下はご自身の環境に合わせてご変更ください。

ホスト名	win2012ad1
IPアドレス	192.168.255.11
ドメイン名	sample.local

・Windows Server 2022を初期インストール状態、IPアドレス割り当て済み状態を用意します。

ホスト名	win2022ad2
IPアドレス	192.168.255.12

準備１

Win2022ad2で作業します。Windows Server 2022を「sample.local」ドメインに参加します。

・DNSをwin2012ad1のIPアドレスにします。

・コンピューターのプロパティを開きます。その後、「このPCの名前を変更（詳細設定）」をクリックします。

・変更ボタンを押します。

・所属するグループを選択して参加先のドメイン名を入力し、「OK」ボタンをクリック後、管理者アカウント情報を入力します。

※以下のエラーの場合：DNS周り、IPv6になっていないかを確認します。

・Active Directoryに参加できたら再起動して準備完了です。

WindowsServer2022のActive Directory追加手順

・サーバーマネージャーから「役割と機能の追加」をクリックします。

・指示に従って進めていき、「サーバーの役割の選択」で「Active Directoryドメインサービス」にチェックを入れます。
※ポップアップで表示されたものは追加します。

・そのまま画面に従って進めていき、「インストールオプションの確認」で「必要に応じて対象サーバーを自動的に再起動する」にチェックを入れ、「インストール」をクリックします。

・インストールが終わり「閉じる」をクリックした後、サーバーマネージャーから「このサーバーをドメインコントローラーに昇格する」をクリックします。

・「既存ドメインにドメインコントローラーを追加する」を選びます。

このときに「ユーザーアカウント名を指定してください。」と表示された場合は「変更」をクリックしてユーザーアカウントをドメインの管理者のアカウントを指定します。

・後は画面に従っていき、「インストール」をクリックしてインストール行います。
SYSVOLフォルダ等は場所を移動するものではないと過去の経験上そう思っています。

再起動が終わって、Active Directoryの同期等が行われます。同期しているので１５分ぐらいは、待ちましょう！

win2012ad1とwin2022ad2の同期確認をする

やっぱりこのあたりは、きちんと行わないと後のトラブルになるのでしっかりと行う必要があります。PDCという言い方はないのですが、もう、古い人間なのとなんだかんだPDCという概念が残っているようなのでそうしています。

操作は、wind2022ad2で実施

・コマンドプロンプトを開いて、同期状態を確認します。

実行コマンド：repadmin /replsummary

失敗が０であることを確認。

テスト用のはきれいにエラーがありません。そりゃ、運用していないので。

ちなみにしばらくぶりにADサーバーをチェックするとこんな感じが一般的かもしれません？気づけよ！？気づかないことが多いですΣ(´∀｀；)
以下のところで対処方法を記述してみました

Win2012AD1サーバーでFSMOの転送処理を行う

作業するサーバーが変わって、「win2012ad1」です。この部分が昔の時代のPDC的なイメージです。そんなことはおいておいて、役割を転送します。

転送する役割は以下の５つです。

・ PDC エミュレーター
・ RID マスター
・インフラストラクチャーマスター
・スキーママスター
・ドメイン名前付け操作マスター

・PowerShellを管理者で開きます。

・以下のコマンドを実行して移行します。１行でできるので便利です。

Move-ADDirectoryServerOperationMasterRole –Identity <宛先ドメインコントローラー名> -OperationMasterRole PDCEmulator,RIDMaster,InfrastructureMaster,SchemaMaster,DomainNamingMaster

・操作マスタ（FSMO）を確認します。PowerShellで以下のコマンドを実行します。

netdom query fsmo

移行できたことが確認できればOKです。

ラスト！Win2012ad1のドメインコントローラーを降格します！

「win2012ad1で作業を行います。」

忘れないうちに、各ドメインコントローラーで降格の優先と代替DNSのIPアドレスを変更します。（win2012ad1の削除）

・サーバーマネージャーから「役割と機能の削除」をクリックします。

・指示に従って画面を進めていき「サーバーの役割」で「Active Directory ドメインサービス」のチェックを外します。

・関連サービスも削除します。

・検証結果がエラーで表示されますがその中にある「このドメインコントローラーを降格する」をクリックします。

・Active Directoryドメインサービス構成ウィザードが表示され、「次へ」をクリックします。

・「削除の続行」にチェックを入れて、「次へ」をクリックします。

・降格後のパスワードを入力して「次へ」をクリックします。

・「降格」ボタンをクリックします。

・再起動が強制的に実施されます。

・ログインを行います。DNSを変え忘れたときは、ドメインでなくローカルでログインしましょう！

・サーバーマネージャーを開き「役割と機能の削除」をクリックします。

・「Active Directory ドメインサービス」と「DNSサーバー」のチェックを外します。

・画面に従っていき、削除を行います。

・削除が終わったら、サーバー再起動を行います。（コマンドだと「shutdown /r /t 0」）

・これで作業は終わりです。

win2022ad2のIPアドレスを「win2012ad1」にしたい場合は、IPアドレスを変更して、サーバーを再起動してください。（win2012ad1はシャットダウンした状態もしくはIPアドレスを変更した後に行ってください）

「このサーバーとの最後のレクリケーション以来、廃棄（Tombstone）の有効期間を超えた時間がたっているため、ディレクトリサービスはこのサーバーでレプリケートできません。」を対処する

これは対処しないとNG案件です。時間経過しているので強制同期スタートです。

レジストリーに下記の強制同期キーを記述して、サーバーを再起動してみた。再起動後は削除

レジストリキー: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\
値: Allow Replication With Divergent and Corrupt Partner
タイプ: REG_DWORD
値のデータ: 1

結果としては前進した！

「(8606) オブジェクトの作成に必要な属性が足りません。このオブジェクトは、削除されて既にガーベジコレクションが行われ、存在しない可能性があります。」を対処する。

「tombstoneLifetime」の値を確認する。

サーバーマネージャーから「ADSIエディター」を開く

・「ADSIエディタ」＞「右クリック」＞「接続」をクリックする。

・「接続ポイント」を「識別名または名前付きコンテキストを選択するまたは入力する」を選択する。

接続値として以下のようにする

例：ドメイン名.localの場合
repadmin /showattr CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=ドメイン名,DC=local /atts:tombstonelifetime

・既定の名前付きコンテキストの下の「CN＝」のプロパティを開く。（表示されなければ、「既定の名前付きコンテキスト」をダブルクリックすれば表示される

・「tombstonelifetime」の値を確認する。これだと180

残りオブジェクトを削除する

＊上記で日数見たけど、結局オーバーしているのは削除しないとというお話なので削除します。

削除するにはGUIDが必要だそうで。GUIDも調べる
削除コマンド：repadmin /removelingeringobjects <Dest_DSA_LIST> <Source DSA GUID> <NC> /ADVISORY_MODE

PDCのサーバーのGUIDを以下のコマンドで調べる。

repadmin /showrepl /v サーバー名

・削除を実行する

repadmin /removelingeringobjects <削除するサーバー＋ドメイン名> <調べたGUID> <DC=のドメイン名指定> /ADVISORY_MODE

・レジストリでレプリケーションを停止する

・レジストリキーの値を０にする

HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Strict Replication Consistency

・Active Directoryサイトとサービスで今すぐレプリケーションを実行し、エラーがないことを確認する。

＊詳しくは以前のこちらの記事を参照

・上記の作業が終わったら、レジストリキーの値を１に戻す。（忘れずに）

・それで最初に戻って同期のエラーがないか確認する

repadmin /replsummary

・追加した以下のレジストリキーを削除する

レジストリキー: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\
値: Allow Replication With Divergent and Corrupt Partner

すこしこの状態で様子を見ましょう！

参考URL

https://jp.fujitsu.com/platform/server/primergy/technical/construct/pdf/win2019-active-directory01.pdf

https://it-trouble.help/%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88id1988active-directory%E3%81%A7%E3%83%AC%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E6%9C%89%E5%8A%B9%E6%9C%9F%E9%96%93%E3%81%8C/

https://learn.microsoft.com/ja-jp/troubleshoot/windows-server/identity/replication-error-8606

https://yanor.net/wiki/?Windows+Server/Active+Directory/%E5%BB%83%E6%A3%84+%28Tombstone%29+%E3%81%AE%E6%9C%89%E5%8A%B9%E6%9C%9F%E9%96%93%E5%88%87%E3%82%8C%E3%81%8B%E3%82%89%E3%81%AE%E5%BC%B7%E5%88%B6%E5%90%8C%E6%9C%9F

Advanced Custom Fields(ACF)のv5系→v6で日付の戻り値、ファイルは気をつけないと

Advanced Custom Fields(ACF)がバージョン6系になって、日付の戻り値がバージョン５と異なっていた。いやそもそもDBへの格納される値が異なっている。

バージョン６からは、「/」が入った日付型になっていてバージョン５は数字だけだったのでおいおいって感じでクエリ等で操作しているときは気をつけたほうが良い。

ファイルで使用していたフィールドの内容変更が反応しない（更新や削除）

フィールド名が異なると問題なく動作する・・・どうしたもんか・・・

っていうか、全体的にACFの内容の編集ができない。どうしてだ。

→WP FrontEndプラグインとACFの連携が有効になっていたため、更新できなかった。連携をオフにした。

ひさびさにサーバー構築してみたらSSHが鍵でログインできない！件

ひさびさにLinuxサーバーを構築してみました。Centosが終わったので「almalinux」にOSの種類を変えてみました。

SSHにはterateam、SCPは、WinSCPという定番を使っております。

SSHで鍵でログインできない件でチェックした事項

・sshの設定でRootユーザーのログイン禁止とパスワード禁止設定されているのか
PermitRootLogin no
PermitEmptyPasswords no

・.sshディレクトリは、700であること

・ .sshディレクトリ配下の公開鍵や認証情報は、600であること

・秘密鍵ファイルの—–END OPENSSH PRIVATE KEY—– の後に改行が入ってないと（これは、キー読み込み時にエラーを吐き出す）

・WinSCPを最新版にする

・SSHクライアントをTeraTeamではなく、Windows10に附属のSSHを利用する

をやってみました。

SSHで鍵を使ってログインできなかった件の結論としては

・Windows側で利用しているクライアントソフトの問題でした・・・

バージョンアップしないとね・・・。

WindowsでもSSHの鍵はセキュリティーでうんぬんって言われるので、該当のキーは利用するユーザーのみに限定して回避しました。

phpexcelからphpspreadsheetに乗り換えたときのメモ

もういい加減「phpexcel」の部分を「phpspreadsheet」に置き換えようとざっくりとそのまま使いまわしして、調整したときに発生した問題をまとめてみました。

■調整事項

mergeCellsByColumnAndRow

１から始まるように変更

setCellValueExplicitByColumnAndRow

１から始まるように変更

Worksheet::getDefaultStyle()

// PHPexcel時
$worksheet->getDefaultStyle();

// phpspreadsheet時
$worksheet->getParent()->getDefaultStyle();

以下のURLがPHPexcelからphpspreadsheetに乗り換えるときに参考になります。
https://phpspreadsheet.readthedocs.io/en/latest/topics/migration-from-PHPExcel/

kinstaでPHP7.4→8.1に変更してざっくりと速度を測定してみた

kinstaでPHP7.4→8.1に変更してざっくりと速度を測定してみました。

なんでざっくりかというとホームページを制作途中のため、ざっくりなページでで試してみましたｗ

ホームページの速度結果

PHPバージョン	HTML読み込み終了までの時間
PHP7.4	1.25秒
PHP8.1	0.952秒

ざっくりと24%速度が改善しています。PHPバージョンを変更するだけでこれだけ改善します。計測用に何度も行ったわけではないのでご参考までに。

※Chromeのデベロッパーツールで計測しました。

アクセス速度を改善したい場合はこれはやるべき事項ですね。

PHP7.4 vs PHP8.1をエックスサーバーで試してみた。

PHP8.1の効果が2022年11月9日時点で効果が確認できかなったので結果掲載はやめました( ;∀;)

「エックスサーバーで運用するときは最新且つ推奨のPHPバージョンを利用しているのがよい！！」

という本日の結論でした。時代とともに変わると思いますが・・・。

とりあえず、エックスサーバーでワードプレスを運用中の方はPHP7.4で今のところ行きましょう！

PHP8でAds by datafeedr.comの管理画面がエラーだとよ。

Ads by datafeedr.comを入れたままPHP8に変更したら、そのまま動作はするが管理画面でエラーが発生なのでざっくりと対応してみた。

なんだかんだ代替プラグインがないこともあるんでどうにかね。

エラー内容：Uncaught TypeError: Cannot access offset of type string on string

配列の問題ね。厳格化になっていっているからね。

エラーを対処するまでの流れ

１．ワードプレスのデバックモードを有効にする

２．エラーのプログラムと行と内容を特定する

３．今回はPHP7系で警告出ていると思うから内容を確認。

４．配列の定義あるときとないときの対処の記述がないのでそのあたりをごにょごにょと記述する。

「(get_option( ‘dfads-settings’ )」の値がないのに「$output[‘dfads_enable_shortcodes_in_widgets’]」＝XXXXって

それはそれは怒られます。

ざっくりとemptyで判定しといた。

    	        $output = array(
			'dfads_enable_shortcodes_in_widgets'=>0,
		);
		if(!empty(get_option( 'dfads-settings' )))
		{
			$output = get_option( 'dfads-settings' );			
		}

もう１箇所出ていたから同じような感じで。

あとは、phpの7と8で試してOKでした。

KINSTAへの道４

実用に向けて色々とやってみました。今回は、アップロードに関してです。

アップロードのファイルサイズは256MB固定です。

変更はできないとのこと。一時的なものは、SFTPなどでアップしてほしいとのこと。

動画配信サーバーとしての利用は禁止！とのこと。

配信サーバーに利用しようとしたんでないけど、動画ファイルアップロードしたいって言われたら、上記のことを言われた。動画配信は別サーバー使うけど。

速度が早い分気を使う点が多数あるので、単純に一般的な日本の共用レンタルサーバーからの移動は調整や作り変えなど必要によっては発生するかもしれません。

基本的にサポートは英語でしたが、Google翻訳でやりとりでOKでした。

KINSTAへの道３

実際のサイトデータを入れてどうかチェックしていきます。

サイトキャッシュ問題

運用想定サイト：会員向けの動的コンテンツがメインでほぼキャッシュ利用できない。

前提：専用サーバーもしくは１CPU,１RAMでないとサイトキャッシュの無効化できないとのこと

→個別に依頼してキャッシュを無効化していただく必要がある。

一時保護のためのサイトパスワードプラグイン

サイト公開まで「Password Protected」プラグインでパスワード保護していることが多いのですが、キャッシュに引っかかりました。

→対象のクッキー情報を送ってパスしていただきました。（プラグインの設定ページ記述されています。）

除外してもらうときの内容

Cookie 名:”bid_1_password_protected_auth”

動的にPDF生成しているページ

はい。キャッシュにヒットしました。

→依頼して除外

admin-ajax.phpでajax通信しているものってどうなのか？

無効化っぽい？です。回答あやふや。まあ、ちゃんと動いていたからいいや

結論：キャッシュが影響したらサポートに問い合わせしてキャッシュ除外をしていただく！！

この一択となりました。

KINSTAへの道２

今日は、kinstaにいれたサイトをdevkinstaを利用してローカルで作業を行ってみたいと思います。

道のり

１．devkinstaをインストールする(ここから)

２．kinstaアカウントでログインする

３．kinstaからデータを持ってくる

４．これで完成

で、開発作業はどうすればよいのか・・・

ちなみに、ローカルでも
・「All-in-One WP Migration」はNGです。

devKinstaの疑問点

まず、ステージング環境が必要？？

ローカルで更新されたファイル、テキスト、メディアなどはどこまでkinstaへ反映させることができるのか？

選択肢としては、ファイルとデータベースという項目があります。
これはステージングからLIVE環境に反映でも同じようにあります。

テンプレートだけならファイル。

各種設定なら、データベースという感じで。DBの部分的なものは手動で反映です。

例：
プラグイン→反映
メディア→反映

まあ、そうですよね。

devKinsta or ステージング環境

どっちが開発しやすいのか・・・

Windows端末を利用しているのでその場合は、ステージングで開発したほうが利用しやすいのでは？って感じもしました。

ざっくりとローカルで作り、ステージングで整え、本番に反映？使い方は色々研究中です。

→なんだかんだPCが重くなった気がしたので削除しました。ステージング環境で十分です。

ステージングからLIVE環境への反映

思った以上に時間がかかるイメージです。

KINSTAへの道

WordPressのサーバーを追い求めていたらKINSTAに出会った。早速試してみようと思ったけど、いつも利用しているバックアッププラグイン「all in one migration」が利用できなく、「Duplicator」というプラグインを利用してくれとのことだった。

※バックアップとキャッシュ系プラグインはkinstaでは利用禁止のため、最初に削除しておく必要があります。

kinstaで公開されている方法になぞっています。

WordPress Duplicatorプラグインを使ってKinstaへ自力でサイトを移行する方法

1.kinstaへ移行するために。。。

１．まず本番と同じドメインでサイト準備する。all in one migrationでサイト複製

２．「１」のサイトで、「Duplicator」でデータを生成する

３．kinsta上は、WEBサイト追加だけを行い、WordPressはインストールしない。

４，「kinsta」のWEBサイトにSFTP等で接続して、「２」のデータ（installer.phpとZIPファイル）をアップロードする

５．「４」でアップロードしたinstaller.phpにアクセスする

６．kinstaのDB情報を入力する。
※先にPHPバージョンを合わせたほうが良い

７．サイトにアクセスする。一部停止になっているプラグインもあるので確認する。

８．「Duplicator」のファイルを削除する

これで、LIVE上にサイトが完了しました。やってみたら、すごく簡単でした。

2.kinstaで本番運用する

１．kinstaでドメインを追加する（ドメイン追加と確認のTXTレコードを追加する）。

２．プライマリドメインにする（ここでドメインの置き換えが行われる）

３．wp-config.phpの「WP_SITEURL」を確認する

前
define( 'WP_SITEURL', 'https://xxxxxxxxxx.kinsta.cloud/' );

↓

変更後
define( 'WP_SITEURL', 'https://本番用URL/' );

４．hostsをkinstaに向けて確認する

５．DNSレコードを変更して本番運用を行う。

3.kinstaから戻す・・・

「1.kinstaへ移行するために。。。」で行ってもよいかと思います。

あとは、Duplicatorプラグインの有料版で実施してもよいかと。

あれ・・・なんかみれない。。

悩んだ結果、自分のところのインターネット回線が問題だったようです。
別回線では問題なかった。

１時間以内にDNSレコードを切り替えたのがいけないかな？？？
時間が解決してくれた。

Email Logというプラグインでメール送信履歴を残しているのだが、kinsta→Xserverへ「Duplicator」プラグインで戻したときに、日時が変わっているものがいくつかあった。

同じIDだが日時が異なる・・・。さして影響は無いのだが・・・