たちまち。

即席で役に立つこと。

作成したjavaファイルとリリース用classファイルの間に漏れがないかを確認する

とあるプロジェクトでJavaファイルを作成した。

リリースするのは、コンパイルされたclassファイルのみである。

リリース用にclassファイルのみ固めたものの、元となるソースが漏れなく含まれているかを確認したい。

ファイル数で確認できそうだが、複数クラス出力するjavaもいるし…

そんな時は以下のようにする。

1. javaのみ固めたフォルダと、classのみ固めたフォルダをそれぞれ用意。
2. コマンドプロンプトを起動し、javaのみ固めたフォルダに移動して、以下を実行。
dir /b /s *.java > javalist.txt

※ファイルリストを取得する。/bはファイル名のみ、/sはサブフォルダを含む。拡張子を絞っている。

3. 同様にclassのみ固めたフォルダに移動して、以下を実行。
dir /b /s *.class > classlist.txt
4. 生成されたテキストをそれぞれエディタで開き、以下のように加工する。

・パッケージより手前のフォルダパスは削除

・拡張子を削除

5. 加工したテキストをWinMerge等の比較ツールで比較

・差異なく表示される。

・1Javaから複数クラス出力されたものは差異として出るが、一見してわかる。

以上、ただの愚直な手順でした。

ViewCreatorのクエリ作成にアクセスすると403権限エラー

掲題の通り、ViewCreatorのクエリ一覧からクエリ作成にアクセスすると、「403 アクセス権限がありません」エラーが発生する。

ログインしているユーザはテナント管理者なのになぜ…

念のため認可を見直してみても、ViewCreator関連の画面・処理権限は全てONになっている。

ユーザを変更してみても特に事象に変化はなし。

解決方法

やはり認可が原因で、welcome-allマッパーに権限が割り当たっていなかった

テナント管理>認可から、welcom-allマッパーに許可権限をつけることで解決した。

調査方法としてはrequestログを確認したところ、403の画面に飛んでしまう直前のリクエストにて「api/tenant/common/messages」を呼んでおり、

このURLでconf内をGrepかけたところ、routing-jssp-configのtenant-common.xmlがヒットし、中身を見るとwelcome-allマッパーに紐づけられていた。

まさかwelcome-allの権限がOFFになっているとは予想外だったが…そんなこともあるようだ。

Dynamics365でダッシュボードを開くと"RELEVANT_MESSAGE_IN_INCORRECT_ENVIRONMENT"エラー

Dynamics365環境にて、ダッシュボードを開くと以下のエラーが発生する。

f:id:aposke:20200901155220p:plain

エラー

RELEVANT_MESSAGE_IN_INCORRECT_ENVIRONMENT

解決方法

クライアント環境に合わないダッシュボードを表示しようとしているため、ダッシュボードの権限設定を見直す。

今回のケースでは、「Outlook用 アプリ ダッシュボード」を表示しようとしてしまっていた(これは、ブラウザページのタイトルで判明した)。

システムのカスタマイズから当該のダッシュボードを選択し、「セキュリティロールの有効化」から全てのロールを外すことで解決。

【Dynamics365】統一インターフェイスのエンティティ用に使える標準アイコン

Dynamics365の統一インターフェイスにした際、サイトマップに配置している各メニューにアイコンが表示されるが、

カスタムエンティティについては、デフォルトでパズルのピースのようなアイコンになっている。

これを変更したい場合は、ソリューションから対象のエンティティを開き、「アイコンの更新」の中に「統一インターフェイス」というタブがあるので、そちらから指定すれば変更できる。

このアイコンについては基本的に自前で用意するのが良いと思うが、標準でも選べるものがいくつか存在する。

標準で使えるいいものはないのかな?ということで、調べてみたものが以下。

f:id:aposke:20200901115309p:plain

f:id:aposke:20200901115321p:plain

f:id:aposke:20200901115330p:plain

f:id:aposke:20200901115340p:plain

f:id:aposke:20200901115348p:plain

f:id:aposke:20200901115356p:plain

この他にも存在するが、使えそうなのはこんなところ。

「msfp_」で始まるアイコンはサイズ・テイストともに統一インターフェイスに最適化されているようだ。

数が多くないのと、マッチしないとあまり使えないケースもあるかもしれないが

主要エンティティのアイコンをちょっと変更したい、という場合には使えるかもしれない。

Dynamics365のPluginRegistrationToolで登録時にエラー

以下のエラーが発生する。

Cannot open Sql Encryption Symmetric Key because Symmetric Key password does not exist in Config DB

解決方法

調べたところ、Dynamicsのデータ暗号化の設定をしていないことが原因の模様。

ブラウザからシステムに画面アクセスし、「設定」>「データ管理」>「データ暗号化」を開いて設定すればよいようだ。

しかし、データ暗号化の画面を開こうとすると以下のエラーに遭遇。

この種類の要求には HTTPS プロトコルが必要です。HTTPS プロトコルを有効にしてからやり直してください。詳細については、インストール後の手順と構成の手順を参照してください。

https環境を構成しないといけないらしい。

しかしhttpsに対応する余裕も予定もないので、DBに対して以下SQLを発行しSSLチェックを無効化する。

UPDATE [MSCRM_CONFIG].[dbo].[DeploymentProperties]
SET [BitColumn]=1
WHERE ColumnName='DisableSSLCheckForEncryption'

その後、APサーバを再起動

再度画面にアクセスすると、データ暗号化の画面が表示された。

暗号化キーの入力欄に暗号化キー(一定の強度が必要)を入力し、設定することでアクティブになった。

その後、再度プラグイン登録を行ったところ無事成功!

参考URL

https://sliong.wordpress.com/2015/03/13/crm-2013-migration-cannot-open-sql-encryption-symmetric-key-because-symmetric-key-password-does-not-exist-in-config-db/

Dynamics365のPluginRegistrationToolで接続時にエラー

対象バージョン:Dynamics365(9.0)

以下のエラーが発生する。

Source   : mscorlib
Method  : HandleReturnMessage
Date    : 2020/08/25
Time    : 14:15:45
Error   : セキュリティで保護されていないか正しくセキュリティで保護されていないフォールトを相手側から受信しました。フォールト コードおよび詳細については、内部の FaultException を参照してください。
Stack Trace : Server stack trace: 
   場所 System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.ProcessReply(Message reply, SecurityProtocolCorrelationState correlationState, TimeSpan timeout)
   場所 System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.Request(Message message, TimeSpan timeout)
   場所 System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)
   場所 System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   場所 System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   場所 System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]: 
   場所 System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   場所 System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   場所 Microsoft.Xrm.Sdk.Discovery.IDiscoveryService.Execute(DiscoveryRequest request)
   場所 Microsoft.Xrm.Sdk.Client.DiscoveryServiceProxy.Execute(DiscoveryRequest request)
   場所 Microsoft.Xrm.Tooling.Connector.CrmWebSvc.DiscoverOrganizations(Uri discoveryServiceUri, Uri homeRealmUri, ClientCredentials clientCredentials, ClientCredentials deviceCredentials, CrmLogEntry logSink)
   場所 Microsoft.Xrm.Tooling.Connector.CrmWebSvc.DiscoverOrganizations(Uri discoveryServiceUri, Uri homeRealmUri, NetworkCredential networkCredential, CrmLogEntry logSink)
   場所 Microsoft.Xrm.Tooling.Connector.CrmServiceClient.DiscoverOrganizations(Uri discoveryServiceUri, Uri homeRealmUri, NetworkCredential networkCredential)
   場所 Microsoft.Xrm.Tooling.CrmConnectControl.CrmConnectionManager.ValidateServerConnection(CrmOrgByServer selectedOrg)
======================================================================================================================
Inner Exception Level 1 : 
Source  : Not Provided
Method  : Not Provided
Date    : 2020/08/25
Time    : 14:15:45
Error   : メッセージのセキュリティを検証しているときにエラーが発生しました。
Stack Trace : Not Provided
======================================================================================================================

解決方法

原因は、ツールを実行しているPCとサーバ側の時刻が合っていないこと。

もしくは、ツールをサーバ側に配置して実行するという手もあるぞ。

DynamicsCRM2015(7.0)からDynamics365(9.0)へアップグレードする方法(オンプレミス)

なかなかに手こずったのでここに経緯と解決を記しておく。

まず、前提としてCRMのアップグレード方法は以下の通りである。

CRMのアップグレード方法

  1. 旧verの組織DBをSQLServerバックアップ
  2. それを新verのSQLServerにリストア
  3. 新verの展開マネージャーにて組織のインポートを実行し、先ほどのDBを指定

この組織インポート時にて古いバージョンの組織DBを入れた場合、CRMが内部で自動的にアップグレードしてくれる。

しかし。

7.0のDBを9.0に持って行って組織インポートを行っても、サポートされないバージョンだと言われてしまう。

一段飛ばしができないため、一度8.2を経由する必要があるのだ。

つまり、7.0から9.0に上げたい場合の手順は以下のようになる。

7.0から9.0へのアップグレード手順

  1. 7.0(現行)、9.0(移行先)、8.2(一時的)の3つのDynamics環境を用意する
  2. 7.0の組織DBをSQLServerバックアップ
  3. それを8.2のSQLServerにリストア
  4. 8.2の展開マネージャーにて組織のインポートを実行
  5. アップグレードされた8.2の組織DBをSQLServerバックアップ
  6. それを9.0のSQLServerにリストア
  7. 9.0の展開マネージャーにて組織のインポートを実行

これでうまくいくのだが、ポイントが1つ。

それはMicrosoft公式ドキュメントにも書いてあるのだが、更新プログラムは最新を適用しようね、ということ。

7.0も、8.2も、9.0も、最新の更新プログラムを適用しておく必要がある。

↓7.0の更新プログラム

https://support.microsoft.com/ja-jp/help/3018363/microsoft-dynamics-crm-2015-updates-and-hotfixes

↓8.0,8.1,8.2および9.0の更新プログラム

https://support.microsoft.com/ja-jp/help/3142345/microsoft-dynamics-365-onpremise-cumulative-updates

また、もし更新プログラムが未適用の状態でアップグレード(組織のインポート)に失敗した場合、

一度展開マネージャーにて該当の組織を削除、さらにSQLServer上の組織DBも削除して、再度旧バージョンのバックアップをインポートした後に

更新プログラムを適用し、改めて組織のインポートが必要になので注意されたし。

以上。