トピック検索
923 件のトピックが該当しました。
- Citrix Print Manager Serviceが停止してしまう - ムラ ( 2006/11/29 11:58:38 更新)
- メタサーバ間でのOutlookの切り替えがうまく行われない - K2 ( 2006/11/22 22:15:59 更新)
- シンクライアント - TAKE ( 2006/11/21 21:02:53 更新)
- ICAクライアントとWebInterfaceのパススルー認証 - やまちゃん ( 2006/11/16 17:40:24 更新)
- クライアントのドライブのマッピングについて - ine ( 2006/11/14 10:45:38 更新)
- WEBクライアントからの公開アプリケーション使用時の、ログオン認証のタイミングについて - meta美 ( 2006/11/11 00:47:34 更新)
- カスタムICAコネクションのIPアドレスによるアクセス制限 - yama ( 2006/11/08 21:40:09 更新)
- アプリケーションを指定した時のスタートアップ - 阿部 ( 2006/11/07 15:48:45 更新)
- IPアドレスによるアクセス制限 - yama ( 2006/11/07 12:01:07 更新)
- 公開デスクトップ上でCtrl＋Cでコピーした文章をローカルPCに保存できないようにしたい - コロコロ ( 2006/10/19 21:36:31 更新)
Citrix Print Manager Serviceが停止してしまう
いつもお世話になっております。
題記の件、プリンタの自動作成時においてエラーが発生し、
印刷が出来なくなる事象が発生しております。
お知恵を拝借したく、宜しくお願い申し上げます。
＜現象＞
①クライアントのデフォルトプリンタのドライバが
CPSサーバにインストールされていない時に発生。
②発生すると、Citrix Print Manager Serviceが停止してしまう。
＃タスクマネージャのプロセスから「CpSvc.exe」も落ちてしまいます。
④一度自動作成されたプリンタは、クライアントがログアウトしても消えない。
かつ一度サービスが落ちると、サービスを再起動するだけでは印刷が出来なくなり、
一度切断し、再接続する必要がある。
また、当然ですが、停止中は新たなクライアントがログインしても
プリンタの自動作成が行われない。
＜質問内容＞
ドライバがインストールされていないクライアントが接続した場合に、
サービスが停止しないようにすることが可能か否か、
ご存知でしたらご教示頂けませんでしょうか？
※ドライバをインストールしておく対応は極力実施しますし、
必須であればその対応で仕方ないとは思っておりますが。。。
＜環境＞
・CPSサーバのOS、SP
→Windows Server 2003 Standard Edition Service Pack1
・CPSのバージョン、エディション
→MetaFramePresentationServerForWindows 4.0.1
・CPSに適用しているHotfix
→OS・CPSともに特に適用なし。
・クライアントPCのOS、SP
→Windows2000 Professional SP4
・ICAクライアントのバージョン
→Ver.8.00.24737
・CPSサーバ上、ポリシーは設定無し。
＜現在の暫定対処法＞
Citrix Print Manager Serviceをエラーが発生した場合、
再起動するようにしておく。
→但し、一度接続したクライアントは一度ログアウトして再接続しないと
印刷が出来ない。
題記の件、プリンタの自動作成時においてエラーが発生し、
印刷が出来なくなる事象が発生しております。
お知恵を拝借したく、宜しくお願い申し上げます。
＜現象＞
①クライアントのデフォルトプリンタのドライバが
CPSサーバにインストールされていない時に発生。
②発生すると、Citrix Print Manager Serviceが停止してしまう。
＃タスクマネージャのプロセスから「CpSvc.exe」も落ちてしまいます。
④一度自動作成されたプリンタは、クライアントがログアウトしても消えない。
かつ一度サービスが落ちると、サービスを再起動するだけでは印刷が出来なくなり、
一度切断し、再接続する必要がある。
また、当然ですが、停止中は新たなクライアントがログインしても
プリンタの自動作成が行われない。
＜質問内容＞
ドライバがインストールされていないクライアントが接続した場合に、
サービスが停止しないようにすることが可能か否か、
ご存知でしたらご教示頂けませんでしょうか？
※ドライバをインストールしておく対応は極力実施しますし、
必須であればその対応で仕方ないとは思っておりますが。。。
＜環境＞
・CPSサーバのOS、SP
→Windows Server 2003 Standard Edition Service Pack1
・CPSのバージョン、エディション
→MetaFramePresentationServerForWindows 4.0.1
・CPSに適用しているHotfix
→OS・CPSともに特に適用なし。
・クライアントPCのOS、SP
→Windows2000 Professional SP4
・ICAクライアントのバージョン
→Ver.8.00.24737
・CPSサーバ上、ポリシーは設定無し。
＜現在の暫定対処法＞
Citrix Print Manager Serviceをエラーが発生した場合、
再起動するようにしておく。
→但し、一度接続したクライアントは一度ログアウトして再接続しないと
印刷が出来ない。
自己レスです。
別ルートで、HotFixの適用を進められました。
①PSJ400W2K3R02.msp
②PSJ400R02W2K3001.msp
③PSJ400R02W2K3002.msp
④PSJ400R02W2k3028.msp
の計4つを①～④の順に、かつHotFix適用毎に再起動し
適用しました(念のため、適用前にはフルバックアップを取得)。
ちなみに、①がCitrix Print Manager Serviceの
HotFixのようです。
その結果、ドライバがインストールされていないクライアントが
接続してもサービスが停止ないようになりました。
まだ本日は実際にシステム運用をしていないので、
本解決に至ったかわかりませんが、まずはご連絡いたします。
お騒がせいたしました。
別ルートで、HotFixの適用を進められました。
①PSJ400W2K3R02.msp
②PSJ400R02W2K3001.msp
③PSJ400R02W2K3002.msp
④PSJ400R02W2k3028.msp
の計4つを①～④の順に、かつHotFix適用毎に再起動し
適用しました(念のため、適用前にはフルバックアップを取得)。
ちなみに、①がCitrix Print Manager Serviceの
HotFixのようです。
その結果、ドライバがインストールされていないクライアントが
接続してもサービスが停止ないようになりました。
まだ本日は実際にシステム運用をしていないので、
本解決に至ったかわかりませんが、まずはご連絡いたします。
お騒がせいたしました。
メタサーバ間でのOutlookの切り替えがうまく行われない
はじめまして。
Outlook2003をメタサーバ2台(※仮に1号機，2号機とします)で
負荷分散させているのですが，
Outlookの実行先のサーバが切り替わったときに，
Outlookの一部機能がうまく継承されず，困っております。
原因・対応方法等，
どのような些細なことでも結構ですので
心当たりのある方はご教授いただけませんでしょうか。
よろしくお願いいたします。
■現象■
1.クライアントAが初めてメタサーバに接続し，
その際，1号機がOutlookを初めて実行したとき，
Outlookの設定としてメールサーバへのネットワークパスワードが求められます。
よって，ネットワークパスワードを入力／保存し，
ログオフ／シャットダウンします。
2.クライアントAが再度メタサーバに接続し，
今度は，(1号機の負荷が大きい等の理由により)2号機がOutlookを実行したとき，
Outlookから，再度ネットワークパスワードを要求されてしまいます。(なぜ？？)
ここで，ネットワークパスワードを再度入力／保存し，
ログオフ／シャットダウンします。
3.再再度クライアントAがメタサーバに接続し，
今度は，1号機がOutlookを実行したときに，
またしても，Outlookからネットワークパスワードを要求されてしまいます。
ただし，上記2でパスワードを入力するが，保存は行わなかった場合だと，
ネットワークパスワードは要求されません。
4.なお，送受信したメールデータについては，
メタサーバが切り替わっても問題なく送受信できています。
■環境■
1.サーバ環境
ADサーバ (WindowsServer2003，単一ドメイン）
メタサーバ (WindowsServer2003，CPS4.0，WebInterface)
ファイルサーバ (WindowsServer2003)
2.クライアント環境
Webクライアント9.0 (OSは，Windows2000およびWindowsXP)
各ユーザアカウントについては，
ターミナルサービスのプロファイルをファイルサーバに格納しています。
Outlookのメールデータもファイルサーバに格納しています。
Outlook2003をメタサーバ2台(※仮に1号機，2号機とします)で
負荷分散させているのですが，
Outlookの実行先のサーバが切り替わったときに，
Outlookの一部機能がうまく継承されず，困っております。
原因・対応方法等，
どのような些細なことでも結構ですので
心当たりのある方はご教授いただけませんでしょうか。
よろしくお願いいたします。
■現象■
1.クライアントAが初めてメタサーバに接続し，
その際，1号機がOutlookを初めて実行したとき，
Outlookの設定としてメールサーバへのネットワークパスワードが求められます。
よって，ネットワークパスワードを入力／保存し，
ログオフ／シャットダウンします。
2.クライアントAが再度メタサーバに接続し，
今度は，(1号機の負荷が大きい等の理由により)2号機がOutlookを実行したとき，
Outlookから，再度ネットワークパスワードを要求されてしまいます。(なぜ？？)
ここで，ネットワークパスワードを再度入力／保存し，
ログオフ／シャットダウンします。
3.再再度クライアントAがメタサーバに接続し，
今度は，1号機がOutlookを実行したときに，
またしても，Outlookからネットワークパスワードを要求されてしまいます。
ただし，上記2でパスワードを入力するが，保存は行わなかった場合だと，
ネットワークパスワードは要求されません。
4.なお，送受信したメールデータについては，
メタサーバが切り替わっても問題なく送受信できています。
■環境■
1.サーバ環境
ADサーバ (WindowsServer2003，単一ドメイン）
メタサーバ (WindowsServer2003，CPS4.0，WebInterface)
ファイルサーバ (WindowsServer2003)
2.クライアント環境
Webクライアント9.0 (OSは，Windows2000およびWindowsXP)
各ユーザアカウントについては，
ターミナルサービスのプロファイルをファイルサーバに格納しています。
Outlookのメールデータもファイルサーバに格納しています。
移動プロファイル設定にて運用した場合はいかがでしょうか？
mal様
ご意見ありがとうございます。
今回の事象は，
移動プロファイルにて運用している中で，
発生しております。
どうやら，特定のユーザのみ本事象が発生しているようなので，
現在，各ユーザのレジストリを比較・検証している最中です。
ご意見ありがとうございます。
今回の事象は，
移動プロファイルにて運用している中で，
発生しております。
どうやら，特定のユーザのみ本事象が発生しているようなので，
現在，各ユーザのレジストリを比較・検証している最中です。
移動プロファイル格納フォルダをリネーム再作成して、
現象がどうなるか確認しては如何でしょう？
プロファイル内に格納されたなんらかの情報が原因か否か、
切り分けが可能かと思います。
現象がどうなるか確認しては如何でしょう？
プロファイル内に格納されたなんらかの情報が原因か否か、
切り分けが可能かと思います。
グレートTS様
ご意見ありがとうございます。
まだ断定できないのですが，
Outlook の Applicaiton Dataのリダイレクトが
ユーザにより異なる挙動をとっているようです。
いただいたご意見も試してみたいと思います。
ご意見ありがとうございます。
まだ断定できないのですが，
Outlook の Applicaiton Dataのリダイレクトが
ユーザにより異なる挙動をとっているようです。
いただいたご意見も試してみたいと思います。
私の所では公開デスクトップにて運用を行っていますが、
pstの格納先をファイルサーバーの共有フォルダに設定していますので、
C:\Documents and Settings\クライアントＡ\Local Settings\Application
Data\Microsoft\Outlookフォルダのリダイレクト機能の設定はしておりませんが
うまく機能しております。
私の所ではoutlookの接続設定情報などは、一度設定するとほぼ変更することはないので、
移動プロファイルの設定が正常に機能していれば、リダイレクトの必要はないと判断いたしました。
pstの格納先をファイルサーバーの共有フォルダに設定していますので、
C:\Documents and Settings\クライアントＡ\Local Settings\Application
Data\Microsoft\Outlookフォルダのリダイレクト機能の設定はしておりませんが
うまく機能しております。
私の所ではoutlookの接続設定情報などは、一度設定するとほぼ変更することはないので、
移動プロファイルの設定が正常に機能していれば、リダイレクトの必要はないと判断いたしました。
Office2003をCPSにインストールする際はOfficeリソースキット(ORK)の
カスタムインストールウィザードを使ってインストールすべきです。
ORKのカスタムインストールウィザードを利用すると、
OutlookのPSTファイルの保存先等をNAS等に変更することが可能で、
（「\\ファイルサーバ名\共有フォルダ名」等を指定可能）
それがデフォルト値となります。
その他メール設定やExchangeに関する設定はほぼ予め設定可能なので、
ユーザは初回にログオンした際に自分のアカウントとパスワードを設定すれば
後は全て設定済みの状態で起動されます。
この方法でOfficeをインストールした場合はK2さんのような現象は発生しない筈です。
カスタムインストールウィザードを使ってインストールすべきです。
ORKのカスタムインストールウィザードを利用すると、
OutlookのPSTファイルの保存先等をNAS等に変更することが可能で、
（「\\ファイルサーバ名\共有フォルダ名」等を指定可能）
それがデフォルト値となります。
その他メール設定やExchangeに関する設定はほぼ予め設定可能なので、
ユーザは初回にログオンした際に自分のアカウントとパスワードを設定すれば
後は全て設定済みの状態で起動されます。
この方法でOfficeをインストールした場合はK2さんのような現象は発生しない筈です。
まだ分析中ですが，，，
どうやらADサーバ同士のsysvol共有がうまく行われていない模様です。
Outlookの導入／設定と同時期に，
グループポリシーの設定変更を頻繁に行っていました。
本来，全メタユーザに共通適用されるはずのグループポリシーが，
sysvol共有がうまく行われていないことにより，
一部のユーザには異なるポリシーが適用され，
それによりリダイレクトの挙動に不一致が発生しているのではないか，
と推測しています。
現在，Outlookの対処よりも，
ADサーバの不具合解消が優先事項となっております。。
どうやらADサーバ同士のsysvol共有がうまく行われていない模様です。
Outlookの導入／設定と同時期に，
グループポリシーの設定変更を頻繁に行っていました。
本来，全メタユーザに共通適用されるはずのグループポリシーが，
sysvol共有がうまく行われていないことにより，
一部のユーザには異なるポリシーが適用され，
それによりリダイレクトの挙動に不一致が発生しているのではないか，
と推測しています。
現在，Outlookの対処よりも，
ADサーバの不具合解消が優先事項となっております。。
横レス失礼します。
きくりん様
＞ Office2003をCPSにインストールする際はOfficeリソースキット(ORK)の
＞ カスタムインストールウィザードを使ってインストールすべきです。
上記のコメントでリソースキットの活用を推奨されていますが、
マイクロソフトより公開されているドキュメント等があったら教えて
いただきたいです。
きくりん様
＞ Office2003をCPSにインストールする際はOfficeリソースキット(ORK)の
＞ カスタムインストールウィザードを使ってインストールすべきです。
上記のコメントでリソースキットの活用を推奨されていますが、
マイクロソフトより公開されているドキュメント等があったら教えて
いただきたいです。
Office2003 と カスタムインストールウィザード でググったら、
一番上に表示されました。。
Office 2003 Editions リソース キット
ツールボックス
カスタム インストール ウィザード
http://www.microsoft.com/japan/office/ork/2003/tools/BoxA03.htm
一番上に表示されました。。
Office 2003 Editions リソース キット
ツールボックス
カスタム インストール ウィザード
http://www.microsoft.com/japan/office/ork/2003/tools/BoxA03.htm
シンクライアント
初めまして
シンクライアントを使用したMetaFrameシステムの導入を検討中です。
質問内容は、ICAのログインについてです。
シンクライアントはWindows XP Embbededを使用した物でICAクライアントが標準で
インストールされています。
通常（ユーザーモード）は、再起動するとデータをおろか設定等も保持されません
ICAを使用する場合で、使用するユーザーが不特定な場合その都度、ユーザー、パスワード、ドメイン
を入力しないとなりません。
そこで、パススルー認証を使用しようと思うのですが、Windows XP Embbededは、ドメイン
参加可能なのでしょうか？
以前、評価機で少しさわっただけで、現在は実機がないので検証できないのです。
導入実績がある方、教えてくれませんか？
シンクライアントを使用したMetaFrameシステムの導入を検討中です。
質問内容は、ICAのログインについてです。
シンクライアントはWindows XP Embbededを使用した物でICAクライアントが標準で
インストールされています。
通常（ユーザーモード）は、再起動するとデータをおろか設定等も保持されません
ICAを使用する場合で、使用するユーザーが不特定な場合その都度、ユーザー、パスワード、ドメイン
を入力しないとなりません。
そこで、パススルー認証を使用しようと思うのですが、Windows XP Embbededは、ドメイン
参加可能なのでしょうか？
以前、評価機で少しさわっただけで、現在は実機がないので検証できないのです。
導入実績がある方、教えてくれませんか？
こんにちは。
＞通常（ユーザーモード）は、再起動するとデータをおろか設定等も保持されません
これは一般的なシンクライアントはそのようになっております。
管理者権限で設定するしか方法はないと思います。
評価機を使用されているということですので、貸してくれたベンダーに問い合わせしてはいかがでしょうか。（評価機の場合は管理者権限をくれない場合が多いため）
＞通常（ユーザーモード）は、再起動するとデータをおろか設定等も保持されません
これは一般的なシンクライアントはそのようになっております。
管理者権限で設定するしか方法はないと思います。
評価機を使用されているということですので、貸してくれたベンダーに問い合わせしてはいかがでしょうか。（評価機の場合は管理者権限をくれない場合が多いため）
HPのt5720を使用しておりますがドメイン参加は可能ですよ。
ICAクライアントとWebInterfaceのパススルー認証
はじめまして。
ICAクライアントとWebInterfaceのパススルー認証にてログインIDが異なる現象が
発生しております。
ICAクライアントからは正常にログインユーザーにて認証を行っているのですが
WebInterfaceからは、ログインユーザーと異なるユーザーにてログインされてしまいます。
WebInterfaceからの認証ユーザーをログインユーザーに直すことはできますでしょうか？
サーバ環境
Windows2003Server
Meta Presentation Server 4.0
PSJ400W2K3R01,PSJ400W2K3R02適用済
WebInterface 4.0.4.5083
クライアント環境
WindowsXP SP2
以上、よろしくお願いいたします。
ICAクライアントとWebInterfaceのパススルー認証にてログインIDが異なる現象が
発生しております。
ICAクライアントからは正常にログインユーザーにて認証を行っているのですが
WebInterfaceからは、ログインユーザーと異なるユーザーにてログインされてしまいます。
WebInterfaceからの認証ユーザーをログインユーザーに直すことはできますでしょうか？
サーバ環境
Windows2003Server
Meta Presentation Server 4.0
PSJ400W2K3R01,PSJ400W2K3R02適用済
WebInterface 4.0.4.5083
クライアント環境
WindowsXP SP2
以上、よろしくお願いいたします。
はじめまして。
もう少し詳しく状況をおしえて頂きたいのですが、
WebInterfaceからログイン（されてしまった）場合
管理コンソール上でどのユーザでログインしていることになっているでしょうか？
全部一意のものであればWI側の設定ではないでしょうか。
もう少し詳しく状況をおしえて頂きたいのですが、
WebInterfaceからログイン（されてしまった）場合
管理コンソール上でどのユーザでログインしていることになっているでしょうか？
全部一意のものであればWI側の設定ではないでしょうか。
レス有難うございます。
WebInterfaceからのログインは、何のユーザーでログインされているかは
わからないのが現状です。接続すると、公開しているアプリケーションが
ありませんと表示されます。
ほかのPCにて同じユーザーでログインして、WebInterfaceに接続した場合は
そのIDでログインされています。
よろしくお願いします。
WebInterfaceからのログインは、何のユーザーでログインされているかは
わからないのが現状です。接続すると、公開しているアプリケーションが
ありませんと表示されます。
ほかのPCにて同じユーザーでログインして、WebInterfaceに接続した場合は
そのIDでログインされています。
よろしくお願いします。
>ほかのPCにて同じユーザーでログインして、WebInterfaceに接続した場合は
>そのIDでログインされています。
端末固有の問題ということですか？
再現性はどの程度でしょうか。
>そのIDでログインされています。
端末固有の問題ということですか？
再現性はどの程度でしょうか。
レス有難うございます。
端末固有の問題かと思います。ほかのPCでほかのユーザーは正常にログインできていますので
再現性は、必ず再現します。一応、IEの何かの問題化と思い、キャッシュやクッキーやらを
すべて削除しても、現象は変わりませんでした。
よろしくお願いします。
端末固有の問題かと思います。ほかのPCでほかのユーザーは正常にログインできていますので
再現性は、必ず再現します。一応、IEの何かの問題化と思い、キャッシュやクッキーやらを
すべて削除しても、現象は変わりませんでした。
よろしくお願いします。
IEの設定の可能性が高いですね。
正常にログインできている端末とできていない端末で
インターネットオプションのマッチングをかけてみてはいかがでしょうか？
あるとすればイントラネットのセキュリティオプション項目に差異が見られると思います。
その他端末自体で差異があれば、（ネットワーク含む）正常にログインできている端末と
比較するのが一番わかりやすいかと思います。
正常にログインできている端末とできていない端末で
インターネットオプションのマッチングをかけてみてはいかがでしょうか？
あるとすればイントラネットのセキュリティオプション項目に差異が見られると思います。
その他端末自体で差異があれば、（ネットワーク含む）正常にログインできている端末と
比較するのが一番わかりやすいかと思います。
レス有難うございます。
両方のPCを見比べてみましたが、設定に違いなどはありませんでした。
よろしくお願いします
両方のPCを見比べてみましたが、設定に違いなどはありませんでした。
よろしくお願いします
>両方のPCを見比べてみましたが、設定に違いなどはありませんでした。
全部の設定ですか？
ネットワーク・OS・アプリケーション・グループポリシー等も見直してみてくださいね。
全部一緒なのにそれだけが特別な動きをするということは現実的にあり得ないと思います。
WIの設定をパススルーから指定ユーザに変更した際の挙動はどうなりますか？
全部の設定ですか？
ネットワーク・OS・アプリケーション・グループポリシー等も見直してみてくださいね。
全部一緒なのにそれだけが特別な動きをするということは現実的にあり得ないと思います。
WIの設定をパススルーから指定ユーザに変更した際の挙動はどうなりますか？
レス有難うございます。
WebInterfaceのログイン情報は、どこを見ているのでしょうか？
IEのオートコンプリートの部分でしょうか？これを消してみても変わらなかったのですが・・・
ネットワーク・OS・アプリケーション・グループポリシー等も見直してみますが
すべて同じに設定してあると思います。
指定ユーザーにて、PCのログインユーザーを指定すると正常にログインでき、公開アプリケーション
が表示されます。
よろしくお願いいたします。
WebInterfaceのログイン情報は、どこを見ているのでしょうか？
IEのオートコンプリートの部分でしょうか？これを消してみても変わらなかったのですが・・・
ネットワーク・OS・アプリケーション・グループポリシー等も見直してみますが
すべて同じに設定してあると思います。
指定ユーザーにて、PCのログインユーザーを指定すると正常にログインでき、公開アプリケーション
が表示されます。
よろしくお願いいたします。
>WebInterfaceのログイン情報は、どこを見ているのでしょうか？
パススルー認証であれば、OSのログイン情報を渡していると思います。（domain\user1等）
別のユーザで２種の端末でログインした場合でも現象は同じですか？
こういう場合はマトリックスを作って検証するのが、障害箇所の特定に役立つと思います。
A=不具合端末
B=正常端末
1=ユーザ１（現象確認済み）
2=ユーザ２（新規ユーザ等）
1.2→A で現象発生 B発生なし→Aの不具合
A →1のみで発生→ユーザ設定の可能性
このような感じの検証を行ってみてください。
#ドメイン設定とか平気ですよね？
#OSログインの際にローカル端末にログインしているとか。。。
パススルー認証であれば、OSのログイン情報を渡していると思います。（domain\user1等）
別のユーザで２種の端末でログインした場合でも現象は同じですか？
こういう場合はマトリックスを作って検証するのが、障害箇所の特定に役立つと思います。
A=不具合端末
B=正常端末
1=ユーザ１（現象確認済み）
2=ユーザ２（新規ユーザ等）
1.2→A で現象発生 B発生なし→Aの不具合
A →1のみで発生→ユーザ設定の可能性
このような感じの検証を行ってみてください。
#ドメイン設定とか平気ですよね？
#OSログインの際にローカル端末にログインしているとか。。。
レス有難うございます。
ドメインの設定などは、正しく行われています。また、ログインはドメインにログインしております。
問題有のユーザー 不具合端末 NG 正常端末 OK
問題無のユーザー 不具合端末 OK 正常端末 OK
という結果になりました。
ドメインの設定などは、正しく行われています。また、ログインはドメインにログインしております。
問題有のユーザー 不具合端末 NG 正常端末 OK
問題無のユーザー 不具合端末 OK 正常端末 OK
という結果になりました。
以上の検証からすると端末固有ではなく、
ユーザ毎の設定みたいですね。
WI系で問題あるとすればIISの設定かと。
問題有のユーザと問題無のユーザともに
CPS上の公開アプリケーションの権限は付与されているか確認してください。
ユーザ毎の設定みたいですね。
WI系で問題あるとすればIISの設定かと。
問題有のユーザと問題無のユーザともに
CPS上の公開アプリケーションの権限は付与されているか確認してください。
レス有難うございます。
問題有のユーザーは、違うPCでは正常に公開アプリケーションが表示されます。
どこかに、ログイン情報が残っているのでしょうか？
問題有のユーザーは、違うPCでは正常に公開アプリケーションが表示されます。
どこかに、ログイン情報が残っているのでしょうか？
クライアントのドライブのマッピングについて
はじめまして。
クライアントのドライブとのマッピングについて教えてください。
MetaFrameで公開されている.Netアプリケーションを起動し
ファイルダイアログ等を開くと、以下のように表示されます。
・C
・D
・'クライアントのE$' (T:)
・'クライアントのD$' (U:)
・'クライアントのC$' (V:)
getLogicalDrive()を利用すると、T:/U:/V:などは取得できますが
ボリューム名「クライアントのC＄」などが取得できません。
例えば、アプリ側でクライアントのC:temp\testフォルダにアクセスするために、
ボリューム名「クライアントのC＄」を取得する方法はありますか？
あるいは、C：→V：、D:→U：などのマッピングのルールがあれば
教えていただきたく。
よろしくお願いいたします。
クライアントのドライブとのマッピングについて教えてください。
MetaFrameで公開されている.Netアプリケーションを起動し
ファイルダイアログ等を開くと、以下のように表示されます。
・C
・D
・'クライアントのE$' (T:)
・'クライアントのD$' (U:)
・'クライアントのC$' (V:)
getLogicalDrive()を利用すると、T:/U:/V:などは取得できますが
ボリューム名「クライアントのC＄」などが取得できません。
例えば、アプリ側でクライアントのC:temp\testフォルダにアクセスするために、
ボリューム名「クライアントのC＄」を取得する方法はありますか？
あるいは、C：→V：、D:→U：などのマッピングのルールがあれば
教えていただきたく。
よろしくお願いいたします。
SHGetFileInfo()でどうですか？
GetVolumeInfoで出来ますよ。
>あるいは、C：→V：、D:→U：などのマッピングのルールがあれば
>教えていただきたく。
割り当たる順番はVから逆順と決まってます。
ただし、サーバードライブのマッピングを
実行している場合を除く。
>教えていただきたく。
割り当たる順番はVから逆順と決まってます。
ただし、サーバードライブのマッピングを
実行している場合を除く。
WEBクライアントからの公開アプリケーション使用時の、ログオン認証のタイミングについて
まだまだインフラ技術もあまりない初心者です。
公開アプリケーションの使用時に、認証を問われるタイミングについて質問で
す。
WEBページからダウンロードしたICAWEBクライアント（ica32t)を使用した場合、
パススルー認証を設定しても、アプリ使用前にログオン認証を要求されるのは、過去ログ等を見て理解しました。
そのログオン認証のタイミングは、CPS4.0と3.0で違うのでしょうか？
環境や設定は以下のようにして、3.0→4.0へのバージョンアップのための検証を行っています。
■環境
環境①
・OS：Windows 2000 Server(VirtualPC上)
・CPSのバージョン：Presentation Server4.0（Advanced Edition）
環境②（現在運用中）
・OS：Windows 2000 Server
・CPSのバージョン：Presentation Server3.0（Advanced Edition）
■設定（両サーバとも）
・公開アプリケーション（メモ帳）の使用許可者はドメインユーザグループを指定している
・WebInterfaceを使用する
・サイトの認証ではパススルー認証を使用する
■現象
環境①（CPS4.0）
・ドメインユーザーでログオンしたクライアントPCで、ブラウザからWebInterfaceにアクセスすると、ログオン済みになっていてメモ帳アイコンが表示されている
・メモ帳アイコンをクリックすると、しばらくして認証画面のダイアログボックスが現れる
・メモ帳を一度終了し、再度使用するためにWEBページ上のメモ帳をクリックすると、再度認証が求められる
環境②（CPS3.0）
・ドメインユーザーでログオンしたクライアントPCで、ブラウザからWebInterfaceにアクセスすると、WEBブラウザ上でログオンを求められる。
・メモ帳を一度終了して、再度実行してもログオンは求められない。（セッションが切れるまで）
（両環境ともにドメインユーザーでログオンしたクライアントPCで、Program Neighborhoodを用いた場合は、アプリ使用前にログオン認証を求められることはありません）
■疑問
どうして4.0と3.0でログオン認証を問われるタイミングが違うのでしょうか？
ただバージョンの違いから起こることなのでしょうか？
こういった現象に関する情報をお持ちの方いらっしゃいましたら、教えていただけませんでしょうか。
よろしくお願いします。
公開アプリケーションの使用時に、認証を問われるタイミングについて質問で
す。
WEBページからダウンロードしたICAWEBクライアント（ica32t)を使用した場合、
パススルー認証を設定しても、アプリ使用前にログオン認証を要求されるのは、過去ログ等を見て理解しました。
そのログオン認証のタイミングは、CPS4.0と3.0で違うのでしょうか？
環境や設定は以下のようにして、3.0→4.0へのバージョンアップのための検証を行っています。
■環境
環境①
・OS：Windows 2000 Server(VirtualPC上)
・CPSのバージョン：Presentation Server4.0（Advanced Edition）
環境②（現在運用中）
・OS：Windows 2000 Server
・CPSのバージョン：Presentation Server3.0（Advanced Edition）
■設定（両サーバとも）
・公開アプリケーション（メモ帳）の使用許可者はドメインユーザグループを指定している
・WebInterfaceを使用する
・サイトの認証ではパススルー認証を使用する
■現象
環境①（CPS4.0）
・ドメインユーザーでログオンしたクライアントPCで、ブラウザからWebInterfaceにアクセスすると、ログオン済みになっていてメモ帳アイコンが表示されている
・メモ帳アイコンをクリックすると、しばらくして認証画面のダイアログボックスが現れる
・メモ帳を一度終了し、再度使用するためにWEBページ上のメモ帳をクリックすると、再度認証が求められる
環境②（CPS3.0）
・ドメインユーザーでログオンしたクライアントPCで、ブラウザからWebInterfaceにアクセスすると、WEBブラウザ上でログオンを求められる。
・メモ帳を一度終了して、再度実行してもログオンは求められない。（セッションが切れるまで）
（両環境ともにドメインユーザーでログオンしたクライアントPCで、Program Neighborhoodを用いた場合は、アプリ使用前にログオン認証を求められることはありません）
■疑問
どうして4.0と3.0でログオン認証を問われるタイミングが違うのでしょうか？
ただバージョンの違いから起こることなのでしょうか？
こういった現象に関する情報をお持ちの方いらっしゃいましたら、教えていただけませんでしょうか。
よろしくお願いします。
以前、CPS 4.0のWeb Interfaceで同様の問題が発生して
悩んだ覚えがあります。
結論としては、appsrv.ini（C:\Documents and Settings
\<user>\Application Data\ICAClient内）に
以下の変数を、[WFClient］セクションに追加することで
認証画面のダイアログは出なくなりました。
---------------------------
EnableSSOnThruICAFile=On
SSOnUserSetting=On
---------------------------
(Web Interface管理者ガイドP61もご参照ください）
> ■疑問
> どうして4.0と3.0でログオン認証を問われるタイミングが違うのでしょうか？
> ただバージョンの違いから起こることなのでしょうか？
の疑問の回答にはなっていませんが、ご参考まで。
「そんなの知ってるわい」の場合は申し訳ありません。
悩んだ覚えがあります。
結論としては、appsrv.ini（C:\Documents and Settings
\<user>\Application Data\ICAClient内）に
以下の変数を、[WFClient］セクションに追加することで
認証画面のダイアログは出なくなりました。
---------------------------
EnableSSOnThruICAFile=On
SSOnUserSetting=On
---------------------------
(Web Interface管理者ガイドP61もご参照ください）
> ■疑問
> どうして4.0と3.0でログオン認証を問われるタイミングが違うのでしょうか？
> ただバージョンの違いから起こることなのでしょうか？
の疑問の回答にはなっていませんが、ご参考まで。
「そんなの知ってるわい」の場合は申し訳ありません。
お礼が遅くなって申し訳ありません。
はやさんも同様の現象で悩まれたということは、
やはり4.0では同じタイミングで問題が発生するのでしょうね・・・
ご回答ありがとうございました。
はやさんも同様の現象で悩まれたということは、
やはり4.0では同じタイミングで問題が発生するのでしょうね・・・
ご回答ありがとうございました。
カスタムICAコネクションのIPアドレスによるアクセス制限
いつもお世話になっております。
Program Neighborhoodにおいて、カスタムICAコネクションの接続を行う場合、クライアントのIPアドレスによるアクセス制限などは行うことはできますでしょうか？
現状ですと、Administratorのユーザー名とパスワードがわかってしまうと誰でも接続することができる状態です。
環境を下記に記します。
＜サーバー環境＞
Meta:MetaFrame Presentation Sever Ver.4.0
OS:Windows Server 2003
＜クライアント環境＞
Meta:Citrix Program Neighborhood Ver.9.1
OS:Windows XP SP2
以上、ご返答のほど、よろしくお願いいたします。
Program Neighborhoodにおいて、カスタムICAコネクションの接続を行う場合、クライアントのIPアドレスによるアクセス制限などは行うことはできますでしょうか？
現状ですと、Administratorのユーザー名とパスワードがわかってしまうと誰でも接続することができる状態です。
環境を下記に記します。
＜サーバー環境＞
Meta:MetaFrame Presentation Sever Ver.4.0
OS:Windows Server 2003
＜クライアント環境＞
Meta:Citrix Program Neighborhood Ver.9.1
OS:Windows XP SP2
以上、ご返答のほど、よろしくお願いいたします。
管理者権限のIDとパスワードが漏れてしまったら、Windows、及びWindows上で
動作するCPS上では基本的には何でもできてしまうわけで。
漏れた場合の対策をCPSに求めるのはちょっと違うと思いますが如何でしょうか？
動作するCPS上では基本的には何でもできてしまうわけで。
漏れた場合の対策をCPSに求めるのはちょっと違うと思いますが如何でしょうか？
ご返答ありがとうございます。
漏れた場合の対策ではなく、漏れないためにIPアドレスによる制限をかけたいと考えております。
一定のアドレスからのみカスタムICAコネクションの接続をさせるようにしてしまえば、ログイン画面にすらたどり着けなくなるためセキュリティが増すと考えております。
外部からのアクセスはファイアウォールにより一定IPしか通さないようにはなっていますが、その一定IPアドレスのかなでも、アプリケーションの公開のみで、ICAコネクションを使わせたくないIPなどが存在します。
このようなことを実現する方法などはないでしょうか？
以上、ご返答のほど、よろしくお願いいたします。
漏れた場合の対策ではなく、漏れないためにIPアドレスによる制限をかけたいと考えております。
一定のアドレスからのみカスタムICAコネクションの接続をさせるようにしてしまえば、ログイン画面にすらたどり着けなくなるためセキュリティが増すと考えております。
外部からのアクセスはファイアウォールにより一定IPしか通さないようにはなっていますが、その一定IPアドレスのかなでも、アプリケーションの公開のみで、ICAコネクションを使わせたくないIPなどが存在します。
このようなことを実現する方法などはないでしょうか？
以上、ご返答のほど、よろしくお願いいたします。
CPS4.0では、ポリシーについてはIPアドレスで適用先を指定できますが、
アクセス制限はかけられません。
そもそも、一般的なミドルウェアがレイヤー3レベルでのフィルタリングを普通行わないと思います。
それはL3スイッチやFWの仕事です。
一番簡単な方法としては、ソフトウェアFWをCPSにインストールし、
社内FWとの多段構成にすればよいと思います。
アクセス制限はかけられません。
そもそも、一般的なミドルウェアがレイヤー3レベルでのフィルタリングを普通行わないと思います。
それはL3スイッチやFWの仕事です。
一番簡単な方法としては、ソフトウェアFWをCPSにインストールし、
社内FWとの多段構成にすればよいと思います。
追記ですが、
該当IPに対して公開アプリケーションのみのアクセスを許したいのであれば、
インバウンドに80(XML)をaccept、アウトバウンドには1494(ICA)若しくは
2598(画面保持機能利用の場合)をacceptし、
例えばターミナルサービス(リモートデスクトップ)が使う3389はdenyにすればよろしいかと。
該当IPに対して公開アプリケーションのみのアクセスを許したいのであれば、
インバウンドに80(XML)をaccept、アウトバウンドには1494(ICA)若しくは
2598(画面保持機能利用の場合)をacceptし、
例えばターミナルサービス(リモートデスクトップ)が使う3389はdenyにすればよろしいかと。
すいません、内容をよく読まずに回答してしまいました。
カスタムICAコネクションでの接続に対して制限できないかってことですよね。
申し訳ありません。
普段の運用の中でAdministrator権限でICAセッションを利用する場合がありますか？
もしAdministratorがRDP接続のみの運用でよろしいのであれば、
コネクション構成ツールからICAセッションのアクセス権でAdministratorを拒否にすれば
カスタムICAコネクションでAdministrator権限でアクセスを試みても
接続できなくなります。
カスタムICAコネクションでの接続に対して制限できないかってことですよね。
申し訳ありません。
普段の運用の中でAdministrator権限でICAセッションを利用する場合がありますか？
もしAdministratorがRDP接続のみの運用でよろしいのであれば、
コネクション構成ツールからICAセッションのアクセス権でAdministratorを拒否にすれば
カスタムICAコネクションでAdministrator権限でアクセスを試みても
接続できなくなります。
出題者の意図は、
Administratorのユーザー名とパスワードがばれてしまう
↓
その結果
↓
誰でもカスタムICAコネクションにて接続することができる状態
↓
になるので、
↓
万が一漏れたとしても、カスタムICAコネクション接続を防ぎたい
なんじゃないのですか？
つまり漏れしまった後のリスクを回避したいと読み取れます・・・
AdministratorのID、パスワードが漏れないようにするために、
カスタムICAコネクションの接続制限をするというのは、
目的と対策がアンマッチしていると思いますが。
PNをインストールする際に、カスタムICAコネクションのコンポーネントを
インストールしなきゃいいのでは？端末を利用する方がローカル管理者権限
を持つアカウントでログオンしていると、PNの削除・インストールが可能なので、
防ぎようがないですけど。
もしくはコネクション構成ツールで「公開アプリケーションのみを実行する」に
チェックをしたらいかがでしょう？
それでもRDPで繋がれたらログオン画面は表示されますので、
コネクション構成ツールでRDPは無効にしないといけないですね。
Administratorのユーザー名とパスワードがばれてしまう
↓
その結果
↓
誰でもカスタムICAコネクションにて接続することができる状態
↓
になるので、
↓
万が一漏れたとしても、カスタムICAコネクション接続を防ぎたい
なんじゃないのですか？
つまり漏れしまった後のリスクを回避したいと読み取れます・・・
AdministratorのID、パスワードが漏れないようにするために、
カスタムICAコネクションの接続制限をするというのは、
目的と対策がアンマッチしていると思いますが。
PNをインストールする際に、カスタムICAコネクションのコンポーネントを
インストールしなきゃいいのでは？端末を利用する方がローカル管理者権限
を持つアカウントでログオンしていると、PNの削除・インストールが可能なので、
防ぎようがないですけど。
もしくはコネクション構成ツールで「公開アプリケーションのみを実行する」に
チェックをしたらいかがでしょう？
それでもRDPで繋がれたらログオン画面は表示されますので、
コネクション構成ツールでRDPは無効にしないといけないですね。
アプリケーションを指定した時のスタートアップ
metaframeXPです
アプリケーションを指定してICAクライアントを作成した場合、ログインユーザーの
スタートアップに登録したプログラムとか動いていないみたいなんですが、そう
なのでしょうか
また、そうであれば、それに代わる方法はありますでしょうか
アプリケーションを指定してICAクライアントを作成した場合、ログインユーザーの
スタートアップに登録したプログラムとか動いていないみたいなんですが、そう
なのでしょうか
また、そうであれば、それに代わる方法はありますでしょうか
バッチファイルを公開アプリとして登録します。
バッチファイルの1行目に、スタートアップに配置したいアプリを起動する記述を行います。
2行目に公開アプリを起動するための記述を行います。
バッチファイルの1行目に、スタートアップに配置したいアプリを起動する記述を行います。
2行目に公開アプリを起動するための記述を行います。
お返事が遅くなりましてすみません
バッチファイルも試してみたのですが、アプリを指定した場合は
アプリを終了するとセッションも自動的に閉じてくれますが
バッチの場合はセッションが残りますよね
あれはどうしようも無いのでしょうか
バッチファイルも試してみたのですが、アプリを指定した場合は
アプリを終了するとセッションも自動的に閉じてくれますが
バッチの場合はセッションが残りますよね
あれはどうしようも無いのでしょうか
セッションが残ったか否かはちょっと未確認ですが、
一定期間使用していないセッションはログオフさせるようなことが
運用的にOKなのであれば、Meta側でそのような設定を行うことで
実現可能だとは思います。
一定期間使用していないセッションはログオフさせるようなことが
運用的にOKなのであれば、Meta側でそのような設定を行うことで
実現可能だとは思います。
IPアドレスによるアクセス制限
いつもお世話になっております。
公開アプリケーションのアクセス制限をユーザーだけではなくIPアドレスも交えた形で公開することができますでしょうか？
現状ですと、公開アプリケーションのユーザーに登録されているユーザー名とパスワードがわかってしまうと誰でもアプリケーションを起動することができる状態です。
METAフレームのサーバーに複数社のアプリケーションを公開した場合、他社同士は公開アプリケーションを使用させないようにしたいと考えております。
各会社では固定IPアドレスが違いますので、このアプリケーションはこのユーザー名、パスワード、IPで使用させるといった形にできればと考えております。
環境を下記に記します。
＜サーバー環境＞
Meta:MetaFrame Presentation Sever Ver.4.0
OS:Windows Server 2003
＜クライアント環境＞
Meta:Citrix Program Neighborhood Ver.9.1
OS:Windows XP SP2
サーバーへは、各社固定IPを使用して接続しております。
ファイアウォールもしようしてIPの許可を行っております。
以上、ご返答のほど、よろしくお願いいたします。
公開アプリケーションのアクセス制限をユーザーだけではなくIPアドレスも交えた形で公開することができますでしょうか？
現状ですと、公開アプリケーションのユーザーに登録されているユーザー名とパスワードがわかってしまうと誰でもアプリケーションを起動することができる状態です。
METAフレームのサーバーに複数社のアプリケーションを公開した場合、他社同士は公開アプリケーションを使用させないようにしたいと考えております。
各会社では固定IPアドレスが違いますので、このアプリケーションはこのユーザー名、パスワード、IPで使用させるといった形にできればと考えております。
環境を下記に記します。
＜サーバー環境＞
Meta:MetaFrame Presentation Sever Ver.4.0
OS:Windows Server 2003
＜クライアント環境＞
Meta:Citrix Program Neighborhood Ver.9.1
OS:Windows XP SP2
サーバーへは、各社固定IPを使用して接続しております。
ファイアウォールもしようしてIPの許可を行っております。
以上、ご返答のほど、よろしくお願いいたします。
CMCの負荷評価基準でアプリケーションごとのIPアドレスの制限が可能かと思います。
範囲指定ですが、同じIPを指定すれば固定IPと同じ働きをするかと思います。
ご参考まで。
ご返答ありがとうございます。
試してみたところ、アプリケーションの公開をIPアドレスでコントロールすることができました。
同じようにカスタムICAコネクションなどもIPアドレスでアクセス制限を行うことはできますでしょうか？
以上、ご返答のほど、よろしくお願いいたします。
試してみたところ、アプリケーションの公開をIPアドレスでコントロールすることができました。
同じようにカスタムICAコネクションなどもIPアドレスでアクセス制限を行うことはできますでしょうか？
以上、ご返答のほど、よろしくお願いいたします。
公開デスクトップ上でCtrl＋Cでコピーした文章をローカルPCに保存できないようにしたい
公開デスクトップ上にて開いたファイルの文字をCtrl+Cでコピーして、
ローカルのPCにてメモ帳などに貼り付けができてしまいます。
セキュリティ上できないようにしたいと思うのですが
良い方法があればご教授いただければと思います。
宜しくお願いいたします。
ローカルのPCにてメモ帳などに貼り付けができてしまいます。
セキュリティ上できないようにしたいと思うのですが
良い方法があればご教授いただければと思います。
宜しくお願いいたします。
ICAツールバー→Citrixコネクション構成ツールにて
コネクションを編集することで実現できますね。
お望みの機能はクライアント設定より
「クライアントのクリップボードマッピングを無効」
にチェックを入れることで実現できます。
ご参考まで。
コネクションを編集することで実現できますね。
お望みの機能はクライアント設定より
「クライアントのクリップボードマッピングを無効」
にチェックを入れることで実現できます。
ご参考まで。
XP FR3以降のMetaFrameを使用しているなら、ポリシー機能でクリップボードマッピングを制御したほうがいいですよ。
Powerful & Beautiful
力強く、美しいシステムを。