投稿者: zen

  • Windows10 のPowershellの最大メモリサイズの変更

    Windows 10(およびWindows Server 2012, 2012 R2, 2016, 2019も同じ)でのPowershellの実行時の最大メモリ数の変更手順。Powershellを実行したときに、メモリを使いすぎたので、制限する。

    変更手順

    1. Powershellを管理者モードで起動する
    2. Powershellのバージョン確認する
      $PSversionTable
      ※Powershellが3.0以降の場合は、追加手順あり。
    3. Powershellのメモリ割り当てサイズの確認
      Get-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB
    4. 設定変更
      Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 2048
    5. プラグインの確認(Ver3.0以降の場合は実行)
      ls WSMan:localhost\Plugin 
    6. プラグインのPowershellの割り当てサイズの確認(Ver3.0以降の場合は実行)
      Get-Item WSMan:localhost\Plugin\microsoft.powershell\Quotas\MaxConcurrentCommandsPerShell 
    7. プラグインのPowershellの割り当てサイズの変更(Ver3.0以降の場合は実行)
      Set-Item WSMan:localhost\Plugin\microsoft.powershell\Quotas\MaxConcurrentCommandsPerShell 2048
    8. 設定変更後WinRMの再起動
      Restart-Service WinRM
    9. 事後確認
      Get-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB
    10. 32bitのPowershellを管理者モードで起動する
    11. Powershellのメモリ割り当てサイズの確認
      Get-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 
      ※もし、32bitのPowershellのメモリが変わっていない場合は、同じように変更する。

    作業ログ。

    PS C:\WINDOWS\system32> Get-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB
    
    
       WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Shell
    
    Type            Name                           SourceOfValue   Value
    ----            ----                           -------------   -----
    System.String   MaxMemoryPerShellMB                            2048
    
    
    PS C:\WINDOWS\system32> Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 2048
    警告: 更新された構成は、プラグインあたりのクォータの値が 2048
    を超えるプラグインの操作に影響する可能性があります。登録されているすべてのプラグインの構成を確認し、影響を受けるプラグ
    インのプラグインあたりのクォータの値を変更してください。
    PS C:\WINDOWS\system32>
    PS C:\WINDOWS\system32>
    PS C:\WINDOWS\system32>
    PS C:\WINDOWS\system32>
    PS C:\WINDOWS\system32>
    PS C:\WINDOWS\system32> ls WSMan:localhost\Plugin
    
    
       WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Plugin
    
    Type            Keys                                Name
    ----            ----                                ----
    Container       {Name=Event Forwarding Plugin}      Event Forwarding Plugin
    Container       {Name=microsoft.powershell}         microsoft.powershell
    Container       {Name=microsoft.powershell.workf... microsoft.powershell.workflow
    Container       {Name=microsoft.powershell32}       microsoft.powershell32
    Container       {Name=WMI Provider}                 WMI Provider
    
    
    PS C:\WINDOWS\system32> Get-Item WSMan:localhost\Plugin\microsoft.powershell\Quotas\MaxConcurrentCommandsPerShell
    
    
       WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Plugin\microsoft.powershell\Quotas
    
    Type            Name                           SourceOfValue   Value
    ----            ----                           -------------   -----
    System.String   MaxConcurrentCommandsPerShell                  2147483647
    
    
    PS C:\WINDOWS\system32> Set-Item WSMan:localhost\Plugin\microsoft.powershell\Quotas\MaxConcurrentCommandsPerShell 2048
    警告: 構成の変更は、WinRM サービスを再起動しないと有効になりません。WinRM
    サービスを再起動するには次のコマンドを実行します: 'Restart-Service winrm'
    PS C:\WINDOWS\system32>
    PS C:\WINDOWS\system32>
    PS C:\WINDOWS\system32> Restart-Service winrm
    PS C:\WINDOWS\system32>
    

    参考
    https://tech.guitarrapc.com/entry/2013/08/02/000842

  • 読了:3月のライオン 15

    今回の3月のライオンは、ちゃんと将棋をしていたので安心した。ここのところ、将棋をさすシーンがなかったので、物足りない気持ちだったので。この巻は、将棋をさしているシーンが多いので、あれることなく、堅実な感じが楽しい。タイトル戦になってほしいけれど、普通の将棋もいい。安定して強いという感じがいい。次の巻が楽しみだ。

  • Android Enterpriseのトークンキーの注意点

    Android Enterpriseのトークンキーを、無料のGmailで発行している場合、トークンを発行しているGmailアカウントが失効すると、Android Enterpriseで、Playストアなどが利用できなくなり、制御が効かなくなる。Gmailのアカウントは、ログインの履歴がないと、利用されていないユーザとみなされて削除や停止されてしまう。そのため、Android Enterpriseのトークンキー発行で使用したGmailのアカウントは、定期的にログインして、アカウントをアクティブな状態に保っておくことが必要。

    もし、アカウントが失効した場合は、新しくGmailのアカウントを発行して、トークンキーの発行をして、MDMに設定する。

    Android Enterpriseで不調な場合は、一度、トークンキー発行で使ったGmailアカウントを確認するとよい。

  • ランチ:トンテキ

    TONTEKING トンテキ150グラム
    Tonteking トンテキ

    今日のランチは、久しぶりに赤坂のTONTEKINGのトンテキ。トンテキソースのシングルの150グラム。

    このトンテキは、豚なのに分厚くても柔らかく肉の旨味がよい。美味しいトンテキランチだった。本当は、肉の量を多くしてご飯をあまり食べないようにすればいいのだけど、ついつい肉はシングルで、ご飯をおかわりしてしまう。

  • Excelのマクロまで、JavaScriptに。。。

    Excel操作をJavaScriptで記録 ~Microsoft、“Office Scripts”をパブリックプレビュー
    https://forest.watch.impress.co.jp/docs/news/1227931.html

    Excelのマクロの記録と操作をJavaScriptでできるようになるとのこと。正確には、TypeScriptベースだけど。「既存のVBAは比較的ハイスキルな開発者向けであるのに対し、“Office Scripts”は入門者から上級者まで幅広い層をターゲットとしている点が大きく異なる。」とあるが、VBやVBAは、癖があるけれど、そんなに難しいだろうか。JavaScriptの方がわかりにくいと思うのだが(とても改善されたけど)。世の中的には、JavaScriptが広く普及したので、そこに合わせてきたということかな。

    そろそろ、本気で、VB(Visual Basic)の寿命が付きそうな感じだな。

  • 「スクショマネー」を試してみたが・・・

    iPhoneのホーム画面のスクリーンショットを買い取るサービスが始まったというので、さっそく試してみた。

    iPhoneのホーム画面撮影で300円、「スクショマネー」公開
    https://japanese.engadget.com/jp-2020-01-08-iphone-300.html

    アプリをダウンロードして、起動して、SMS認証が必要というので、認証した。

    iPhoneのホーム画面なら、何枚目でもよいとのことなので、主に使う画面のスクリーンショットを取得した。「スクショマネー」の画像買取から、スクショを指定して、注意書きを読んで、応募した。そして、「買取エントリーの上限に達しています」と、ここで表示され、終了した。最後の最後まで行って、買取されずに終わるとは、UXとしては最悪だ。画像を選ぶ前に、教えてくれればよいのに。あと、画像を選択したときの画面がiPhone8で重なっていたり、切れていたり、ちょっとお粗末。まぁ、見た目の部分は、まぁ、妥協でいいのかもしれないけど。

    スクリーンショット1枚で、300円だから、1万人が応募して、300万円の出費。まぁ、簡単に財源が尽きるのもわからなくはない。

  • 海南鶏飯のチキンライス

    海南鶏飯 蒸し鶏のチキンライス
    海南鶏飯 蒸し鶏

    今日のランチは、赤坂の海南鶏飯で蒸し鶏と鶏飯(シンガポールのチキンライス)を食べた。鶏がサッパリとしていてよかった。鶏飯は、しっかりと味がするので、蒸し鶏がなくても、ご飯だけでも食べられる。

  • Oracleカレンダー

    Oracleの2020年のカレンダー

    普通のカレンダー。シンプルでワンポイントの社用犬がいい。昨年はゲット出来なくて、マイクロソフトのカレンダーだった(それもシンプルで良かった、紙質良かったし)。Oracleのカレンダーの紙がちょっと薄いのが気になる。

  • 長い正月休みも終わり

    今回の正月休みは、カレンダーも味方したので、10連休を取得してみた。正月を中心に行動したので、長い休みのはずが結構忙しく慌ただしく過ぎてしまった。何をやったのかというと、あまりゲームは進まず、本は少々読んだのみ。どちらかというと、ドラマの連続視聴が多かった。

    最終日になって振り返ってみると、もうちょっと本を読めたんじゃないか、もうちょっと勉強できたんじゃないか、と思ってしまう。何もできていないわけじゃないが、もう少し何かができるとよかったのもしれない。さて明日からはまた仕事の日々だ。

  • 読了「デジタル・トランスフォーメーションにまつわる5つの誤解」

    Diamond Harvard Business Review 2019年12月号の記事。

    バズワードのようにデジタル・トランスフォーメーション(DX)という言葉が先行しているが、何をやったらいいのか、ということには大規模な例ばかりの事例の中で、この特集は、企業の身の丈にあうようなことを進めるうえでの良著だった。

    DXは概念的な側面が強いため、これといった絶対的な解はない。ゆえに何をやったらよいのかわからず、とりあえず新しいシステム導入などに走りやすいので、DXの言葉に踊らされずに、まずは自分たちの足元を見直すという意味でも、このDXの誤解について語られた論文はよい。何かディスラプティブなことをやらなきゃならないんじゃないか、という呪縛から解き放ってくれる。DXの言葉に踊らされることなく、本業の課題を考えて、できること、やるべきことを決めてやっていくことが大切だ。

    いくつか気になった部分を抜粋。

    DXの本質は、組織に大混乱をもたらす破壊的(ディスラプティブ)なものではないという。実際は、より段階的なアプローチを使用することで成功している企業が多いからである。

    広くもてはやされている「デジタル・トランスフォーメーション」(DX)という用語の意味は単に、「デジタルテクノロジーが実現する機会を獲得するための、組織的な戦略と体制を導入するということ」である。

    もはやデジタルテクノロジーはIT分野だけの専売特許ではなく、企業のバリューチェーンのほぼすべての部分で導入が進んでいるのだ。マネジャーたちが追い求めるべき機会や優先すべき変革プロジェクトについて頭をめぐらすと、途端にデジタル・トランスフォーメーションが自社にとって具体的に何を指すのか、よくわからなくなる。それも無理はないことなのだ。

    デジタル・トランスフォーメーションといえども、自社の存在理由は変わらないとわかれば、自社がフォーカスを当てるべきテクノロジーを特定しやすくなる。デジタルがもたらす混乱によってコアビジネスの大変革を迫られると思い込んでいるマネジャーは、あらゆる方向に迷走することになる。しかし、自社の課題は単純に、顧客の課題により的確に対応することだと考えるマネジャーは、顧客に与える効果(たとえば顧客体験や顧客関係のシナジー効果)や顧客のコアケイパビリティに与える効果(たとえばコスト面のシナジー効果)が最も大きいテクノロジーに集中する可能性が高い。

    デジタル化がしばしば、非効率な仲介者を外し、コストのかかる物理的インフラを排除できることは間違いない。とはいえ、これはリアルな存在が完全に消えてなくなるということではない。実際には、各種資料で十分に証明されているように、多くの小売業者が、リアルとデジタルのそれぞれの利点を活かした、ハイブリッドモデルの構築方式を見出しつつある。そしてこのことは小売業に留まらず、消費者を相手とする他の業界でも同じ流れを確認することができる。

    企業はしばしば、スタートアップを買収し、それを統合することによって新たなテクノロジーやアイデアを利用しようとする。しかし、このアプローチには、スタートアップの文化を潰し、その企業が創生期に獲得した人材を追い出してしまうリスクがある。賢明な企業は、スタートアップとの間で折衷的な関係を築くことを選ぶ。つまり、学びやシナジー効果が得られる程度に強固で、文化を壊さない程度に緩い関係だ。そして、たとえそのスタートアップの所有権を握るとしても、彼らに半独立的な事業運営を認めるのである。

    マネジャーはしばしば、デジタル・トランスフォーメーションとは、主にテクノロジーの変化に関係するものだと考える。もちろんそれもそうだが、賢明な企業は、変革とは最終的には顧客のニーズによりよく答えることであると考える。その手段としてオペレーションの効率化、マス・カスタマイゼーション、新たな商品・サービスの提供が必要だということだ。このような目的を実現するため、デジタル化は、従来縦割り化されていた活動の横の連携を可能にする。そのため、企業は多くの場合、人員とテクノロジーの両方の再編成を迫られる。実際問題として、これは体制の変化を意味する場合がある。たとえば、敏捷性の高い体制(アジャイル体制)が有効な状況ならば、プロジェクトを最初から最後まで遂行するのに必要な能力と権限を持つ分隊を社内で立ち上げる。分隊はチームの一種ではあるが、起業家的なスタイルで重要な問題を迅速に解決する権限を与えられているという点で、一般的な大企業のチームとは異なる。

    デジタル・トランスフォーメーションでは、最終的に、顧客には見えないバックエンドのレガシーシステム刷新が必要になる場合がある。しかし、いきなりITシステムの全面的かつ徹底的な見直しに着手するのは、非常に危険である。賢明な企業は、顧客に見えるフロントエンドのアプリケーションを速やかに開発しつつ、レガシーシステムをモジュラー型の敏捷なシステムに徐々に置き換えていく方法を見つけ出す。これはたとえば、フロントエンドとバックエンドを結ぶミドルウェアインターフェースを構築したり、事業部門に目下必要なソリューションの導入を認めたりする一方で、バックエンドのシステム改革を抜け目なく進めるといった方法で実現できる。いずれレガシーシステムの機器は役目を終えるが、顧客ニーズへの対処方法を改善するにあたり、それを持っている必要はない。

    たとえ混乱の脅威をまともに受けている企業であっても、デジタル・トランスフォーメーションは多くの企業にとって、通常は提供価値やビジネスモデルの抜本的な再構築を意味するものではない。むしろ、デジタルツールを使ってコア業務を改革することと、デジタルがもたらす新たな機会を見つけてとらえることの両方を意味する。

    成功の秘訣は、顧客ニーズに対するフォーカス、組織の柔軟性、斬新的な変化の尊重、そして新しいスキルやテクノロジーは買収するだけでなく保護しなくてはならないという認識である。そしてこれらは、優秀な従来型企業が昔から得意としてきたことなのだ。