技術:2009年
2009年12月29日
LANボードでチーミングという機能があります。1GのLANボードを2枚利用して、冗長化や帯域UPできるというものです。
とりあえず試しなので、おじゃあお木 を参考に、玄人志向 GbE-PCIe を使って行ってみました。
インストール・設定が完了すると、画像のとおり2Gでリンクアップしています。
basic を利用しましたが、 今後はリンクアグリゲーションとかの設定をして、最大限に速度を利用したいですね。
とりあえず試しなので、おじゃあお木 を参考に、玄人志向 GbE-PCIe を使って行ってみました。
インストール・設定が完了すると、画像のとおり2Gでリンクアップしています。
basic を利用しましたが、 今後はリンクアグリゲーションとかの設定をして、最大限に速度を利用したいですね。
2009年12月28日
ある1台のPCがファイル共有を開いたときに、一部の共有フォルダしか表示されなくなりました。それ以外については全く正常な動作をしています。
PCの再起動を行っても特に変化はありません。該当PCのイベントビューアにもエラーは出ていませんでした。
なお、表示されている一部のフォルダに対して、プロパティを表示させようとすると、「サーバーはリモート要求を受け付けません」という表示がでます。
色々調べたところ、コンピュータアカウントのリセットを行い解決しました。
ADの「ActiveDirectoryユーザーとコンピュータ」から、該当のコンピュータアカウントを検索し、右クリック−アカウントのリセット でOKです。
とりあえず解決したので、しばらく様子を見たいと思います。
#追記
上記作業は、ドメインからの離脱と同等になります。一時的には解決しますが、ドメインへの再ログオンが必要になります。ということで、素直にドメイン離脱→再起動→再ログオンした方がいい感じです。
PCの再起動を行っても特に変化はありません。該当PCのイベントビューアにもエラーは出ていませんでした。
なお、表示されている一部のフォルダに対して、プロパティを表示させようとすると、「サーバーはリモート要求を受け付けません」という表示がでます。
色々調べたところ、コンピュータアカウントのリセットを行い解決しました。
とりあえず解決したので、しばらく様子を見たいと思います。
#追記
上記作業は、ドメインからの離脱と同等になります。一時的には解決しますが、ドメインへの再ログオンが必要になります。ということで、素直にドメイン離脱→再起動→再ログオンした方がいい感じです。
2009年12月27日
※構成としては以下の通りです。
DCは2台構成、今回リプレースするのは、FSMOなどの役割を負っているメインのサーバーです。
■リプレースするサーバー(旧PC)
1. FSMO を転送する
http://support.microsoft.com/kb/324801/ja
※各種役割も転送させる
2. グローバルカタログの移動 or 解除
3. ドメインコントローラから降格
4. ドメインからはずれ、Workgroup環境に。IPも変える
※参考サイトを確認すると非常に簡単ですね。
ただし、実際には確認は相当に注意深くする必要があります。降格の前にイベントビューアを確認して、深刻な警告やエラーが出ていないことを確かめておきます。
■もう一台のDC
・役割が転送されていることを確認する
・ActiveDirectoryサイトとサービスに該当PCが無い事を確認
・ActiveDirectoryユーザーとコンピュータで Domain Controllers に該当PCが無い事を確認
■新しいPC
・PC名、IPアドレスを旧PCと同一にする
・Workgroup環境 → ドメイン参加
・昇格する
※必要に応じて役割を元に戻します。
これで特に問題ありませんでした。
参考
Active Directoryドメインコントローラの降格
もしエラーがでてどうしても降格できない場合には、強制的に作業を行います。
ドメインコントローラがクラッシュした時のアクティブディレクトリ削除方法
DCは2台構成、今回リプレースするのは、FSMOなどの役割を負っているメインのサーバーです。
■リプレースするサーバー(旧PC)
1. FSMO を転送する
http://support.microsoft.com/kb/324801/ja
※各種役割も転送させる
2. グローバルカタログの移動 or 解除
3. ドメインコントローラから降格
4. ドメインからはずれ、Workgroup環境に。IPも変える
※参考サイトを確認すると非常に簡単ですね。
ただし、実際には確認は相当に注意深くする必要があります。降格の前にイベントビューアを確認して、深刻な警告やエラーが出ていないことを確かめておきます。
■もう一台のDC
・役割が転送されていることを確認する
・ActiveDirectoryサイトとサービスに該当PCが無い事を確認
・ActiveDirectoryユーザーとコンピュータで Domain Controllers に該当PCが無い事を確認
■新しいPC
・PC名、IPアドレスを旧PCと同一にする
・Workgroup環境 → ドメイン参加
・昇格する
※必要に応じて役割を元に戻します。
これで特に問題ありませんでした。
参考
Active Directoryドメインコントローラの降格
もしエラーがでてどうしても降格できない場合には、強制的に作業を行います。
ドメインコントローラがクラッシュした時のアクティブディレクトリ削除方法
2009年12月26日
最近、僕のまわりで利用するのはほとんど64bitの端末です。他の管理者がどうしてもという場合には、32bitを利用しますが、最初の候補では間違いなく 64bit を選択します。
そして色々注意点があるように思うので、メモしていきたいと思います。
・安定しない
ドライバ関連です。
だいたいがチップセットか、ディスク(AHCI)関係です。そしてこのドライバの問題は、PCの根本的な安定性に関わります。これが結構やっかいです。サーバーでブルースクリーンとかないわ。。
最新の64bitドライバをインストールしても解決しないことが多いので、切り分けとかがすごい大変です。
・インストールできるハードウェア
サーバーで利用する程度のハードウェアや周辺機器はほとんど問題ありません。LANボードとかHDDそのぐらいはほぼどんな製品でも使えます。
しかしプリンタあたりからすごく微妙になってきます。プリンタは使えるのが多いので、たまに使えない製品に当たると、すごくショックです。
・アプリ
利用できるアプリに少しだけ制限があります。しかしほとんどの場合は、64bitの方が速度も速いですし、メリットの方が多いように思います。
注意しなければならないのは、パッチやドライバ関連です。それ以外はフリーソフトも含めてほとんど大丈夫です。
安定してしまえば本当に最強なのですが、どうも安定させるまでが大変です。
そして色々注意点があるように思うので、メモしていきたいと思います。
・安定しない
ドライバ関連です。
だいたいがチップセットか、ディスク(AHCI)関係です。そしてこのドライバの問題は、PCの根本的な安定性に関わります。これが結構やっかいです。サーバーでブルースクリーンとかないわ。。
最新の64bitドライバをインストールしても解決しないことが多いので、切り分けとかがすごい大変です。
・インストールできるハードウェア
サーバーで利用する程度のハードウェアや周辺機器はほとんど問題ありません。LANボードとかHDDそのぐらいはほぼどんな製品でも使えます。
しかしプリンタあたりからすごく微妙になってきます。プリンタは使えるのが多いので、たまに使えない製品に当たると、すごくショックです。
・アプリ
利用できるアプリに少しだけ制限があります。しかしほとんどの場合は、64bitの方が速度も速いですし、メリットの方が多いように思います。
注意しなければならないのは、パッチやドライバ関連です。それ以外はフリーソフトも含めてほとんど大丈夫です。
安定してしまえば本当に最強なのですが、どうも安定させるまでが大変です。
2009年12月23日
2009年12月20日
2009年12月19日
会社の事情で、 desknet's の構築をしています。個人的にはシェアの高い、もやは定番となっている別ソフトの方がいいのではないかと思ってるのですが、色々その当たりは選択する理由があるようです。
さてこのソフト、インストールするのにサポートが有効期限内である必要があります。そのため、たとえばソフトの購入から1年経過し、保守が切れたとします。もちろん保守は、問い合わせの時にしか通常は利用しないので、製品の利用には問題ありません。
そしてたとえばハードウェアのリプレースなどで、サーバーを交換する場合があります。このときに、新しいサーバーにデスクネッツをインストールするには、保守に連絡をして、コードをもらう必要があります。そのため、再インストールという特に問い合わせる必要無い程度の作業であっても、保守が必須になってしまいます。
もちろんライセンス違反を防ぐためにもこういったことは必要かもしれません。しかしちょっと厳しすぎるように僕としては感じ、柔軟な運用を妨げているように思います。
ちなみに、他社の製品では昔の事ですが、そこまでは厳しくなかったように記憶しています。
さてこのソフト、インストールするのにサポートが有効期限内である必要があります。そのため、たとえばソフトの購入から1年経過し、保守が切れたとします。もちろん保守は、問い合わせの時にしか通常は利用しないので、製品の利用には問題ありません。
そしてたとえばハードウェアのリプレースなどで、サーバーを交換する場合があります。このときに、新しいサーバーにデスクネッツをインストールするには、保守に連絡をして、コードをもらう必要があります。そのため、再インストールという特に問い合わせる必要無い程度の作業であっても、保守が必須になってしまいます。
もちろんライセンス違反を防ぐためにもこういったことは必要かもしれません。しかしちょっと厳しすぎるように僕としては感じ、柔軟な運用を妨げているように思います。
ちなみに、他社の製品では昔の事ですが、そこまでは厳しくなかったように記憶しています。
