カテゴリー: 技術系

  • SQL ServerがインストールされたサーバをP2Vしたら起動時にイベントログにエラーが記録される

    イベントログに記録されていたログは下記。

    イベントID 455
    ソース ESENT
    msmdsrv (1400) ログ ファイル C:\Windows\system32\LogFiles\Sum\Api.log を開いているときに、エラー -1032 (0xfffffbf8) が発生しました。
    
    イベントID 489
    ソース ESENT
    msmdsrv (1400) 読み取るためにファイル "C:\Windows\system32\LogFiles\Sum\Api.log" を開こうとしましたが、システム エラー 5 (0x00000005): "アクセスが拒否されました。 " が発生したため開けませんでした。ファイルを開く処理は、エラー -1032 (0xfffffbf8) のため失敗します。
    
    イベントID 490
    ソース ESENT
    msmdsrv (1400) 読み取りまたは書き込みのためにファイル "C:\Windows\system32\LogFiles\Sum\Api.chk" を開こうとしましたが、システム エラー 5 (0x00000005): "アクセスが拒否されました。 " が発生したため開けませんでした。ファイルを開く処理は、エラー -1032 (0xfffffbf8) のため失敗します。

    このエラーは、「C:\Windows\system32\LogFiles\Sum」のRead/Writeのアクセス権がないため、SQL Serverの起動時にログのフォルダを参照できずにエラーが記録されている。

    対応方法は下記。

    1. SQL Serverを実行しているユーザをサービスから調べる。

    2. 「C:\Windows\system32\LogFiles\Sum」のプロパティを開き、セキュリティからユーザを追加し、Read/Writeの権限を付ける。権限を付けるユーザが見つからない場合は、セキュリティを緩めた

    3. Windowsを再起動して、同じログがでるかを確認する。

    これで完了。

  • SQL Serverでプロシージャーの実行がエラーになる

    SQL Serverのプロシージャーの実行権限は、プロシージャーごとに、ロールまたはユーザに対して権限を付与する必要がある。権限を付与しておかないと、プロシージャーの実行ができない。(すっかり忘れていた)

    SQL Server Management Studioを使っている場合は、該当のプロシージャーを選択して、プロパティを開いて、権限の部分で、ユーザやロールを指定して、権限を付与する。

    https://docs.microsoft.com/ja-jp/sql/relational-databases/stored-procedures/grant-permissions-on-a-stored-procedure?view=sql-server-ver15

  • SQL ServerでViewの作成時に照合順序の競合エラーが出た

    SQL ServerでViewの作成時に照合順序の競合エラーが出た。Japanese_CS_ASとJapanese_CI_ASで照合順があわないとのこと。Select文を単体で実行するとエラーにはなっていない。

    equal to 操作の"Japanese_CS_AS"と"Japanese_CI_AS"間での照合順序の競合を解決できません。

    調べていくと、DB上のテーブルの照合順は、「Japanese_CI_AS」で統一されていた。Select文を見直していくと、Where句で照合順を指定しており、これがテーブルと異なっていたため、競合エラーが発生していた。VIEWのときは、テーブル側と照合順が合致している必要があり、これを見落としていたのが原因だった。WHERE句で指定していた照合順をDB上のテーブルで指定されているものに変更した。

    WHERE  項目名 = '値' COLLATE Japanese_CS_AS

    注意としては、照合順を厳密に指定しておく必要がある場合には、指定が変わってしまう。その場合は、検索で一致させるものを変更するなどの対応が必要。

  • .NET Core 3.1をAzure上でサポート期間後も使い続けられるのか?

    LTSの .NET Core 3.1が2022年12月3日に延長サポートが終了する。オンプレミスの環境ならば、自己責任で使い続けられるのだが、Azure上だとどうなるのかが気になり調べていた。それでやっと見つけたのが、下記の記事だ。

    https://azure.microsoft.com/ja-jp/updates/extended-support-for-microsoft-net-core-31-will-end-on-3-december-2022/

    https://azure.microsoft.com/ja-jp/updates/netcore31/

    2022年12月3日を過ぎても、Functions でホストされているアプリケーションは引き続き実行され、アプリケーションは影響を受けないとのこと。いきなり使えなくなるということはなさそうだ。サポート切れ後に、新しく.Net Core 3.1でデプロイできるのかどうかは不明だが、この書き方だと当面は大丈夫そうではある。

    しかし、Azure側の推奨としては、「潜在的なサービスの中断やセキュリティの脆弱性を回避するには、2022 年 12 月 3 日までに、Functions アプリケーションをランタイム バージョン 4.x (.NET 6 を使用する)に更新」することが求められている。何かセキュリティ的な問題が発生した場合には、短い期間で.NET Core 3.1のアプリケーションの実行が打ち切られるということもあり得るということ。さっさとLTSの.NET6に移行しろということだ。

    Azure App Serviceのインスタンスでも、App Service でホストされているアプリケーションは引き続き実行され、既存のワークロードには影響しないとのこと。ただし、同じように.NET6への移行が推奨されている。

  • GASからMySQLに接続して、コミットする

    通常は、自動コミットされるので、Update文やInsert文を実行したタイミングで、コミットされる。DBへの複数の書き込み処理を、同じタイミングで行うのは、自動コミットをオフにして、手動でコミットする必要がある。

    自動コミットを無効にするには、DBコネクションの「.setAutoCommit(false)」を使用する。

    手動でコミットするには、DBコネクションの「.commit()」を使用する。

    試してみたところ、オートコミットをオフにした場合、「.commit()」を実行しなくても、エラーにはならない。GASのエディタ上でもアラートを上げてくれないので、注意が必要。

    サンプルコード

    function myFunction() {
      dbConnection();
    }
    
    // --------------------------------
    // SSL 接続なしで接続する
    // --------------------------------
    function dbConnection(){
      Logger.log('start dbConnection function.');
    
      // 接続先設定
      var connectionIp = 'xxx.xxx.xxx.xxx'; // 接続のMysqlのIPアドレス(ホスト名も可)
      var userName = 'user'; // 接続で使うユーザ名
      var passwd = 'password'; // 接続で使うパスワード
      var databaseName = 'database'; // データベース名
    
      var addr = 'jdbc:mysql://' + connectionIp + '/' + databaseName;
      Logger.log('start mysql con');
      Logger.log(addr);
    
      var connectionInfo = {
        user: userName,
        password: passwd
      }
    
      // DBにコネクションをはる
      var connection = Jdbc.getConnection(addr, connectionInfo);
      Logger.log(connection.getCatalog());
    
      // オートコミットを無効にして、手動でコミットするようにする。
      connection.setAutoCommit(false);
    
      // sqlステートメントをデータベースに送信するためのオブジェクトを作る
      var statement = connection.createStatement();
    
      // Insert文を発行
      var resultInsert = statement.executeUpdate('Insert Into List (id,listname) values ("5","kanagawa")');
    
      // 実行結果が0なら失敗、1以上なら成功
      Logger.log(resultInsert);
    
      // 手動でコミットする。通常はオートコミットされるので必要なし。
      connection.commit();
    
      // ステートメントを閉じる
      statement.close();
    
      // コネクションを閉じる
      connection.close();
    }
  • GASのDB接続で、オートコミットになっているかを調べる

    コネクションの「.getAutoCommit()」を実行することで、DBへの書き込みがオートコミットになっているかどうかを調べることができる。

    「.getAutoCommit()」の結果が、Trueならオートコミット、Falseなら手動コミット。手動コミットの場合には、「.commit()」を明示的に実行しないとDBにコミットされない。

    サンプルコード

      // DBにコネクションをはる
      var connection = Jdbc.getConnection(addr, connectionInfo);
    
      // オートコミットを無効にして、手動でコミットするようにする。
      connection.setAutoCommit(false);
    
      // Trueならオートコミット、Falseなら手動コミット。ログに書き出す。
      Logger.log('オートコミットの設定: ' + connection.getAutoCommit());
  • ASP.NETでChrome対応したらJSでテキストボックスに値が入らなくなったときの対応

    IE用に作られたASP.NETのアプリを、Chrome対応(Chromium Edge対応)しているときに、JavaScriptでASP.NETのパーツのテキストボックス(type=text)に値をいれたところ、値が入らないということがおきた。「getElementById(“ID”).value」に、JavaScriptから値をいれたが、IE11では問題ないのに、Chromeだと値が入らなかった。

    document.getElementById("ID").value = "値";
    // ↑これだと、IE11は値が入るが、Chromeだと入らない。

    PostBackは発生させていない処理なのだが。いろいろと調べていき、Chromeの場合は「.defaultValue」を使って初期状態の値を書き換えれば、画面の表示が変わることを確認できた。

    document.getElementById("ID").defaultValue = "値";
    // ↑Chromeの場合は、defaultValueを書き換える。

    IE11も残しておく必要があったので、ブラウザの種類をみて、IF文でIEとそれ以外で分岐させるようにした。

    サンプル。

        // ブラウザを取得する
        var userAgent = window.navigator.userAgent.toLowerCase();
        if (userAgent.indexOf('msie') != -1) {
            // IEのときの処理を書く
            document.getElementById("ID").value = "aaaa";
        } else {
            // IE以外の処理。ChromeやChromium Edgeの想定
            // document.getElementById.value だと、画面上の表示が変わらないことがわかった。
            // そのため、document.getElementById.defaultValue に変更したところ、うまくいった。
            document.getElementById("ID").defaultValue = "aaaa";
        }
  • FreeBSDでpkgをアップデートしたらMariaDBが起動しなくなった

    FreeBSDで、”pkg upgrade”して、パッケージを最新の状態にしたところ、MariaDBが起動しなくなった。エラーログをみていると、DBのテーブルを修復したあとにDBがシャットダウンされている。DBのファイル破損が原因かと思い、いろいろと調べて対応したが、実はファイルの問題ではなかった。

    原因は、MariaDBのバージョンが「MariaDB 10.5」に上がったことによる「my.cnf」ファイルの変更だった。

    /usr/local/etc/mysql/conf.d/my.cnf

    このconf.dのディレクトリに、my.cnfがあることで、これを読みにいって、その設定で失敗して、サービスが落ちていた。同じところに、client.cnfもserver.cnfもあるが、これを読まずにmy.cnfを先に読みにいって、落ちていた。my.cnfは、1つ上の階層の「/usr/local/etc/mysql/」にもあり、conf.dの下を読み込むように書かれている。

    いろいろと行ったのだが、対応の正解は、conf.dの下のmy.cnfを消す(リネームでOK)。server.cnfとclient.cnfの設定を確認して、MariaDB(mysqld_safe)を起動させる。

    ちなみに、errファイルに記録されていたログは下記。あとは、ログ自体が出力されていない。ログがそもそも出力されていなければ、my.cnfを疑うべきだった。

    2022-02-05 15:36:39 0 [Note] /usr/local/libexec/mariadbd (initiated by: unknown): Normal shutdown
    2022-02-05 15:36:39 0 [Note] Event Scheduler: Purging the queue. 0 events
    2022-02-05 15:36:39 0 [Note] InnoDB: FTS optimize thread exiting.
    2022-02-05 15:36:40 0 [Note] InnoDB: Starting shutdown...
    2022-02-05 15:36:40 0 [Note] InnoDB: Dumping buffer pool(s) to /var/db/mysql/ib_buffer_pool
    2022-02-05 15:36:40 0 [Note] InnoDB: Restricted to 2016 pages due to innodb_buf_pool_dump_pct=25
    2022-02-05 15:36:40 0 [Note] InnoDB: Buffer pool(s) dump completed at 220205 15:36:40
    2022-02-05 15:36:40 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
    2022-02-05 15:36:40 0 [Note] InnoDB: Shutdown completed; log sequence number 1363646560; transaction id 111190553
    2022-02-05 15:36:40 0 [Note] /usr/local/libexec/mariadbd: Shutdown complete
  • VMware vCenter Converter Standalone 6.2 でWindows Server 2003 の変換がエラーになる。

    VMware vCenter Converter Standalone 6.2 でWindows Server 2003 を仮想マシンに変換しようとしたところ、Agentのデプロイで「Error code: 1,603」でエラーになった。

    サポート範囲を調べてみると、Windows Server 2003は、Windows Server 2003 R2 SP2がサポート対象で、R2が付かないバージョンはサポート対象外だった。

    サポート外だが、無理やりP2Vできなかと、Converter Agentだけのインストールをためしてみたが、サービスをオンにするところで、失敗してロールバックした。

    調べてみると、VMware vCenter Converter Standalone 5.0 であれば、無印のWindows Server 2003にインストール可能。試してみたところ、5.0であればインストールはできた(過去にインストーラーを取得しておいてよかった)。しかし、VMware vCenter Converter Standalone 6.2からの接続は、接続経路の暗号化方式の不一致により、エラーになった。

    今度は、vCenter Converter Standalone 5.0 から、ESXi6.7に対して、P2V先を指定してみたが、これも通信時の暗号方式の問題で接続できずエラーになった。

    Veeam Backupのエージェントを、Windows Server 2003(無印)にいれて、イメージバックアップして、そのイメージを仮想マシンとして復元する方法も試した。Veeam BackupもVersion 9.5でも.net frameworkのバージョンが古すぎて、Windows Server 2003(無印)にエージェントのインストールができず。イメージバックアップを取得して、仮想マシンとしてリストアする方法についても失敗した。

    そのため、vCenter Converter Standalone 5.0を使って、Windows Server 2003(無印)を一度、VMware Workstation形式の仮想ファイルに変換した。次に、このVMware Workstation形式のファイルを、vCenter Converter Standalone 6.2で指定し、V2V(Virtual to Virtual)で、ESXi6.7に対して保存した。これで、なんとかP2Vは成功した。ネットワークの設定などは、変わっているため、仮想マシンの設定を編集して、新しくネットワークインターフェースの割り当てを行った。これで無事にWindows Server 2003(無印)のP2Vは完了した。

    仮想化すれば延命はできるが、物理サーバとして存在していると、そもそもP2Vでの仮想化の対象外になってしまう。延命するのであれば、早めに仮想化しておく必要がある。というのが、今回の教訓になった。

  • Windows10 ver.21H2でOfficeツールへのログインでTPMのエラーがでる。

    クリーンインストールした直後のWindows10 Ver.21H2で、Officeツール(Microsoft 365のWordやExcelなど)にログインすると、TPMのエラーが出てログインできない。エラーの内容は下記。

    問題が発生しました
    
    ご使用のコンピュータのトラステッドプラットフォームモジュールが正しく機能していません。このエラーが解決しない場合は、システム管理者に連絡して、エラーコード 80090034 をお知らせください。
    
    サーバメッセージ: 暗号化に失敗しました

    試したことは・・・

    • これの対処として、PCを工場出荷状態に戻して再セットアップしたり、TPMのクリアなども行ったが、解決できなかった。
    • M365のアカウントも作り直してみたが、関係なし。
    • エラーになったユーザで、別のPCでログインすると問題なし。
    • PCのローカルアカウントでログインすると、M365アカウントでログインできるが、Active Directoryのユーザだと、このエラーが発生する。
    • BitLockerでドライブを暗号してみたが、M365のアカウントのログインではエラーになる。BitLockerの暗号化は正常に終了しているのに。

    最初は1台だけだったのだが、同じセットアップで、かつ別メーカーのPCでも、同じ現象が発生することがわかった。2台で同時に発生しているので、TPMの故障という可能性は薄くなった。

    さらに切り分けていった結果、2022年1月のWindows Update(つまり今月のWindows Update)で配信されていた「KB5009543」をアンインストールして、WordやExcelからM365アカウントでログインすると正常にログインできた。PCを再起動させてみたが、再起動後もログインされた状態はキープされており、問題がなかった。

    Windows10の21H2で、AD環境で、2022年1月のWindows Updateで、KB5009543が適用されており、新規にM365のアカウントで、Officeにログインをするときに発生する問題と思われる。Windows Updateは厄介だ。

    このM365でアカウントでログインするときのTPMのエラーの調査だけで、先週から何時間というか何日使ったことことだろうか。Windows Updateは厄介だ。最新版にして、これなので、辛い。

    追記。

    Windows11でも同じことが発生して、そちらはWindows Updateのアンインストールでは解消しなかった。かわりに、レジストリキーの変更で回避できる。レジストリキーでの対処は、Windows10でも有効だった。方法は下記。