前回までの投稿の作業を実施すれば、Dynamics CRMは利用可能である。
ここでは、いわゆるチューニングというようなものに位置づけられる設定に関して記述する。
以下のサイトが非常に充実していると思う。これらを実施すればいい。
ただ、実践的な観点から言うと、何かを実施すればその根拠や効果の説明が必要となる。
いずれにしても工数がかかる。できるのであれば効果がない（薄い）ものや説明がし難いものは実施したくない。
そこで私が有効であると思っているものだけ取り上げてみる。
①IISに関する設定
体感的にレスポンスアップを感じるレベルの設定である。
認証時に401エラーを発生させる通信を制限させる設定である。
この意味合いや効果に関しては下記を一読頂ければわかるかと思う。
http://blogs.msdn.com/b/crmjapan/archive/2012/03/02/how-to-decrease-401-responses-in-crm-web.aspx
設定方法
crmdom\crmadminでCRMAPサーバにログインする
コマンドプロンプトを管理者として起動して、「C:\Windows\System32\inetsvr」に移動
「appcmd set config /section:windowsAuthentication /authPersistNonNTLM:true」を入力してEnter
②SQL Management Studioでの設定
3つ紹介する。両者ともの手動でのCRM操作レベルではあまりレスポンス改善がされないと私は感じている。
大量処理や一定のケースで効果を発揮するものかもしれない。どれもSQL DB一般での設定である。
1つ目は「MAX DOP」である。
解説は下記がわかりやすい。
http://www.atmarkit.co.jp/ait/articles/0701/17/news131_3.html
実際の設定は下記
crmdom\crmadminでSQL Serverにログインし、SQL Management Studioを起動する
[オブジェクトエクスプローラー]最上部のサーバ名を右クリックし、[プロパティ]をクリック
[ページの設定]から[詳細設定]をクリックし、[並列処理の最大限度]の値を「1」に変更して[OK]をクリック
2つめは「tempdbの分割」である。
解説は以下がわかりやすい。
http://blogs.msdn.com/b/jpsql/archive/2013/01/17/do-s-amp-dont-s-17-tempdb-cpu.aspx
実際の設定は下記
crmdom\crmadminでSQL Serverにログインし、SQL Management Studioを起動する
[データベース]>[システムデータベース]から[tempdb]を右クリック[プロパティ]をクリック
[ページの選択]から[ファイル]をクリック
CPU数と同じになるようにtempdbを作成する。※以下は4CPU（4Core）の場合
3つめは「初期サイズの変更とMB単位の拡張」である。
解説は以下がわかりやすい。
実際の設定は下記
crmdom\crmadminでSQL Serverにログインし、SQL Management Studioを起動する
対象はCRMの組織DB（CRM_MSCRM）、コンフィグDB（MSCRM_CONFIG）、tempdbである。
2つめの画面と同じ箇所で、[初期サイズ（MB）]を自動拡張が発生しないようなサイズに変更し、
[自動拡張/最大サイズ]は%ではなく、MBで指定し、無制限にしておく。
③メンテナンスジョブの実行時間変更
Dynamics CRMをインストールするとメンテナンスジョブが作成され、定期的に実行される。
実行時間は夜間など、サービス時間外（に順ずる時間）にしておくべきである。
これに関してはツールが存在する。
http://crmjobeditor.codeplex.com/releases/view/117948
利用方法に関しては下記が分かりやすい。※exeの保存先に注意
④[最初に行う設定]を表示させない
チューニングではないが、初期設定の一貫で。
Dynamics CRMサイトへの初回アクセス時に、[最初に行う設定]という女性の画面が表示される。
閲覧する必要性はほとんどないため、非表示にするようにする。
crmdom\crmadminでCRMサーバにログインし、レジストリエディターを起動する
「HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM」に移動する
[MSCRM]右クリック[新規]>[DWORD（32ビット）値]をクリック
以上。
実践 Dynamics 365/CRM 〜2017 
いつも、勉強させてもらってます。
AP・DB構成でDynamicsCRMを構築しています。（実際の構築はベンダー）
わけあってAPサーバとDBサーバのIPアドレスを変更しました。
その結果、DynamicsCRMのログイン画面が出なくなってしまいました。
IP変更したことが直接の原因かは分かりませんが、設定を変えたのはIPアドレスくらいです。
何かご存じでしょうか？ヒントだけでももらえると助かります。
一般的にはIPを変更しても問題ありません。以下該当するものはありますか？
・APサーバーのIPにアクセスすると正常起動する。
・ADサーバーとは全く異なるネットワークに属するIPにした
・インターネットから接続できるようIDFの構成をとっている。
・ロードバランサー、データベースミラーリングなどホストレベルのなんらかの冗長化を構成している。
さっそくのご回答ありがとうございます。
APサーバのIPにアクセスしても起動しません。
ADサーバは、AP内に組み込んでいるので同一ネットワーク。
インターネットには未接続
ロードバランサーなども一切なし
APサーバ上で、表示されるエラーは、
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 – Could not open a connection to SQL Server)
でしたのでSQL Server絡みかと思い、いくつか調べたのですが、
DBサーバのファイアーウォールは無効
DBサーバのポート番号1433については、netstatコマンド見る限り、listeningになってました。
ただ、APサーバからDBサーバへのping確認で、IP接続は出来るのですが、ホスト名での疎通が通りません。
APサーバからDBサーバに対して名前解決できる必要はありますでしょうか？
ここのログを見ろとかあればご教示頂けると助かります。
Active Directoryでの変更が必要でした。
変更したら上記の事象は解決しました。
が、このログインは信頼されていないドメインからのログインなので、Windows認証では使用できません。のエラーが。。。
もう少し調べます。。。
エラー内容に関しては、クライアントPCが参加しているドメインとCRMサーバが参加しているドメイン
が異なると共に、両ドメイン間に信頼関係がないため発生しているものであると思われます。
ありがとうございました。
最終的には解消しているのですが、特別何かをしたわけではなく、時間がたったら解決？してました。
いろいろ背景が詳しくないので、明確な理由がかけなくてすみません。
以前伺った内容なのですが、以下のエラーがでてCRMにログインできません。。。
ドメインもAP（＋AD）、DBがともに一つ存在するのみです。
何か確認する点などありますでしょうか？
[2015-02-12 13:52:39.171] Process: w3wp |Organization:00000000-0000-0000-0000-000000000000 |Thread: 223 |Category: Application |User: 00000000-0000-0000-0000-000000000000 |Level: Error |ReqId: d30089ba-52ff-449c-9e5f-db2924836a96 | ClaimsUtility.InitializeApplication ilOffset = 0x7
>Unloaded AppDomain since exception occurred in Application_OnStart ClaimsUtility.InitializeApplication: System.Data.SqlClient.SqlException (0x80131904): ログインできませんでした。このログインは信頼されていないドメインからのログインなので、Windows 認証では使用できません。
at System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject)
直接参加しているActive DirectoryサーバのDNSを確認してみてください。
変更したIP情報が正しく反映されているか確認してみてください。
そのほかとしては、接続端末のインターネットオプションのプロキシ設定を確認してもいいかもしれません。
おかしな参照をする設定がないか確認させてもいいと思います。
以降はドキュメントに基づくものではありませんので、慎重に進めて頂いたほうがいいと思いますが、
それぞれのサーバをドメインから外して、再度参加させてみるのもいいと思います。
同一セグメント上で、上記操作をしたからといって、原則システムが不具合を起こすものではないと思います。
ただ、なんらかの問題で参加できなくなるという可能性はあります。
類似環境で試したり、不具合が起こったとしても、ある程度の余裕がある状況で実施されるのがよいかと思います。
回答ありがとうございます。
私も調べてみましたが、DNSに関するADのトラブルはいろいろあるようですね。
状況的にもADのDNSのIPを直接修正したことは間違いないので関係がありそうです。
一応全て設定は見直してIP自体は正しく設定されており、今は、正常に動いておりますが、おそらくサーバー再起動すると一定時間（おそらく数時間）はアクセス不可になる可能性が高いですね。
動きをみる感じでは、ADの認証をするドメインコントローラーが認識されない為に、認証処理がされずに直接SQLServerにアクセスし、認証されていないのでエラーになっているように思えます。
ただ、なぜそういう動きになっているのかまでは分かっていません。。。