投稿

2019の投稿を表示しています

デバイスコントロールは解決したよ

先月から悩まされてたApex One(Mac)のデバイスコントロール機能の不具合は、TrendMicroさんより修正プログラムの提供を受けて解決しました。

起動するたびにUSBメモリーやUSB接続HDDのマウントが解除されてしまうのは、利用者にとっては苦痛だったと思うよ。
ただ、この問題の問い合わせをしてきたのは一人だけという・・・数十人対象になってるはずだし、ログを見てると接続解除されているんだけど・・・気が付いていないのか、問題として感じていなかったのか・・・

情シスの立場からすると、問い合わせがなかったので楽でよかった。と思う反面、正常動作していないことを認識していないユーザーが存在するのか?連絡しなくても対応してくれると思われているのか?など、不安に思うことがあります。

ちなみに問い合わせをするときに「なんで●●なの?」から始められると嫌だな~と。
こっちは、あなたのトラブルの詳細を知らないし、これから調査していくのだから、「なんで?」と問われても「なんででしょうね」としか答えられない。
「〇〇な状態で困ってるので助けて」って言ってくれると「解決できるように頑張るよ!」って返しやすいんだけどねぇ~

ちょっとした表現の違いで、やる気に差が出るよねぇ~人間だし・・・

最近のトラブル

なーんか最近トラブルが多いよなぁ~と思ったメモ
TrendMicro ApexOne(Mac) 2019 ビルド2141(エージェント3.5.2089) デバイスコントロール機能のON/OFFにかかわらず、USBメモリー等がマウント解除される不具合。
同製品の実行開始時、ポリシー適用時にフルアクセスに設定していてもマウント解除される。
マウント解除された後、手動でマウント操作すると利用できるので、刺し直したりすれば使えるけど、常に接続しているUSB接続HDDなどが切断されてしまうので面倒。
サポートに問い合わせているが、回避策の提案すらない・・・
Intel I219-LM(rev30)とCentreCOM FS7**でPing応答が1000msを超える 該当のコントローラーを搭載したパソコンのみで発生している。
いまだに、FS705とかを使っている点は置いておいて、こいつにつなげるとなーんかネットワークが遅いというか通信が滞ってる感じ。
特定のノードにPingを打ってみるとUSBのLANアダプターでは1ms以下で安定しているのに、内臓LANポートだと1000msを超えたり、タイムアウトを起こしている。
パケットチャプチャしてみたけど、特に問題はない。とりあえず遅い。
rev10だと問題なさそう。
端末側と上位側で違いがあるか調べてみないとなぁ~と

直接接続しているときだけ症状が出るのでなんだろう?って感じ。

netstat -eで破棄とエラーパケットの値が増えているのでなんかあるよね~

LANスイッチ交換すれば解決できるから無視ってのもありだけど・・・

継続しないと忘れるよね

久々に有休を使いまして・・・(正確には代休)
仕事以外のことを使用と思い立ち、
とはいえ、仕事が趣味みたいなものなので、
まぁ、仕事みたいなものですが・・・
趣味の領域でやっているVisual Studio Code extensionの更新をやったのですよ。

前回の更新は去年の4月ってことは1年半放置してたってことですよね。
公開者責任もほぼ放棄しちゃってますね。
使っている方には申し訳ないです。

公開しているのはYAMAHA Routerなんですけどね、
色を付ければ読みやすくなるかもってやつです。


でね、久々に更新すると、いろいろ忘れてしまってて・・・
でも、頑張ってコピペして新しい定義を追加しまして
公開しようと思ったんですけどね、
やっぱりさっぱり忘れてまして、

「vscode extension 更新」でbingってしまうありさまで・・・
とりあえず、vsceってコマンドを使うのですが、
バージョンが古いから更新しろと怒られまして、
npm install -g vsce を実行
で、公開済みのパッケージを更新する際は次のコマンド
vsce publish <version番号>
で、エラーになりました。
色々調べててわかったのですが、
Azure DevOpsでPersonal Access Tokenの期限切れでした。
ってことで再取得して再登録
vsce login <パブリッシャー名>
これで再度公開コマンドで無事公開することができました。

であとはGitHubにアップ?しておわり。
こういうのって定期的にやっておかないとだめですよねぇ~
ほんと、すぐ忘れる。


お掃除ロボットより自分でやったほうが早いよね

イメージ
お掃除ロボットが我が家にきて1か月ほどたったわけですが、毎日一通りお掃除してくれています。

たまに扇風機のコードや紐に引っかかったり、出られなくなって助けを求めてきますが、おおよそ1時間半ほど働き、充電ドックへさまよいながら戻っていきます。

ほんと、さまよいながらです。掃除完了通知の後、その部屋にドックはあるのですが、よく見失うようで別の部屋まで探しに行っていることがしばしば・・・
少ないセンサーですが、マップ作製するなど、もう少し賢い動きができればよいのにねぇ~と思います。機能を持った上位機種はありますが、うちのは考慮されている感じはありませんね。

センサーとしては落下防止、接触センサー、赤外線センサー、そして近接センサーが多分あります。
落下防止センサーがあるおかげで2Fの掃除を任せても安心です。
近接センサーが多分っていうのは、ぶつかる前に止まったり、ゆっくり進むことがあるので多分ついているんでしょうね。でも、カーテンとかに反応して要るっぽいので結構おバカです。

走破性は結構高いです。集めのカーペットや段差も軽々乗り越えていきます。接触センサーにあたらない高さならどんどん攻めていくし、パワーもあるので部屋の隅々まで突き進んでいってます。ちなみに、雑誌なんかも軽く乗り越えて、タイヤでグシャッとしてくれるので要注意です。

というわけで、天敵となるのはコード類とぎりぎり通れる場所になります。で、この辺は大体同じ場所なので、モノを動かしたり、紐を床に放置しないようにすれば無事お掃除を完了するってわけですね。

お掃除ロボットが我が家にきて一番の変化は、床に物を置かなくなった点ですね。
部屋が片付かないって悩んでいる人は購入してみると、モノの置く場所が変化していつの間にか片付いている気がします。

今、迷惑メールが欲しいです。

簡単に届くようになる方法ってありませんかねぇ~

アカウントが存在するだけで届けてくれるi.s*ftb*nk.jpとかうらやましいですね。

それにしても、DMARCってなんで普及しないんでしょうかねぇ~
DKIMを導入しろと言われたら大ごとだけど、
SPF+DMARCならDNSサーバーの設定書き足すだけで終わるのにね~

高い迷惑メールフィルターとかにお金払う前に、DMARCの設定すればいいのにね
世界中の人が設定すれば、相当数の迷惑メールが減ると思うんですよね

DMARCやSPF、DKIM検証なんてしなくてもいいんですよ。
自分の管理するドメインを迷惑メールに利用されにくくするだけでいいんですよ。

メールサーバーを更改するとか、変更する際に検証機能を必須条件にすればよくて、それまでは、ドメインを守るだけでいいんですよ。

DMARCが普及するだけで、なりすましメールによる迷惑メールが撲滅できるんです。

ほんと、無料でできる対策をなんでしないんでしょうか?

ブログ記事でIPアドレスを扱うとき・・・

前の投稿でIPアドレスを書いたんだけど、
はじめはClassAの10.0.0.1って書いたんだよね。
で、読み直したら、IPアドレスに触れない人にとって、IPアドレスって認識してもらえないかも?とおもったので、ClassCの192.168.0.1に書き換えた。

家庭用ルーターの多くは192.168.1.1が初期値に設定してあるし、192.168って続けばIPアドレスか~って直感的に読んでくれるとありがたいと思った。

個人的には、利用者パソコンとかを接続するセグメントはClassAで読みやすく、
バックボーンはClassBにしたい。

ClassCは家庭用ルータをはじめ、IPアドレスが設定されている謎の企業向け機器などの初期値として使われているので利用は避けている。

ClassAのどこがいいって、10.<拠点番号>.<フロア番号>.<ノード>って区切り良く表現できるとこだよ。まぁ、255拠点以上あって255階以上高層ビルを持つ大企業には無理だけど、たいていの企業はこれで十分なんだよなぁ~

もうIPv4は枯渇してていまさら何言ってんだ?とか言われそうだけど、
IPv6の企業内利用のセオリーなんてまだ聞いたことないぞ。
聞こえてこない。

オンプレミスSharePoint Serverのバージョンアップに備える5 まとめ

なんとなくシリーズ化させて書いていますが、簡潔にまとめます。
文字が増えると間違いも増えるので注意が必要だ。



パスベースのサイトコレクションが増えるとバージョンアップで確実に困る。
ホスト名付きサイトコレクションなら何とかなる。

ホスト名付きサイトコレクションだ!!


と個人的には思ってます。
少なくとも私はホスト名付きサイトコレクションに救われました。
ぜーんぶホスト名付きサイトコレクションにしたら多分不幸になるのでやりすぎは注意。

オンプレミスSharePoint Serverのバージョンアップに備える4

ところで・・・

構成A
http://contoso/sites/TeamA
http://contoso/sites/TeamB http://contoso/sites/TeamC http://contoso/sites/TeamD http://contoso/sites/TeamE
構成B
http://TeamA.contoso/
http://TeamB.contoso/ http://TeamC.contoso/ http://TeamD.contoso/ http://TeamE.contoso/
構築が簡単なのはどっち?
答えは構成A

サイトコレクションを作成するとき楽なのはどっち?
答えは構成A

ユーザーにサイトコレクションを自由に作成させたい。楽なのはどっち?
答えは構成A

バージョンアップするときに楽なのはどっち?
答えは構成A。

バージョンアップ中の更新禁止時間が長いのはどっち?
答えは構成B(たぶん)

毎週土曜日に、一つずつバージョンアップすることができるのはどっち?
答えは

オンプレミスSharePoint Serverのバージョンアップに備える3

コンテンツデータベース内のサイトコレクション数っていくつが良いの?
 偉い人教えて~~~

個人的な意見ですが、どんなに詰め込んでもよいのでは?と思ってます。
とはいえ、100GBを超えないようにするのが良いようです。
100GBに近づいてきたら Move-SPSiteで一部のサイトコレクションを別のコンテンツデータベースに移動させることをお勧めします。

もし、一つのサイトコレクションのサイズが100GBを超えそうな状態なら、それ以上サイズが増えないように、何かを頑張ってください。

URLが変わってもよいという協力的なユーザーに恵まれているなら、Export-SPWeb, Import-SPWebでサブサイトを別のサイトコレクションにコピーして、サイズを減らしましょう。


とりあえず、運用中は1対1がベストだし、バージョンアップ時は、コンテンツデータベースが少ないほうが楽。だと思う。

オンプレミスSharePoint Serverのバージョンアップに備える2

データベース接続方式って素晴らしいよ。

SharePointのサイトコレクションはコンテンツデータベースに保存されていて、サーバー構成情報とは分離しているので、このサイトコレクションで新バージョンや検証サーバーしたいと思ったら、該当のコンテンツデータベースのバックアップを作成し、新環境のデータベースにリカバリして接続すれば、サーバー名が異なっても問題なく動作する。
サーバー名が異なるのでリンク切れとか発生する場合もあるけど、普通に動作する。

サイトコレクションの変更はすべてコンテンツデータベースに保存されるので、やり直したいときも、コンテンツデータベースを差し替えるだけでよい。

いろいろ試したいなぁと思ったときにすぐできるのが非常に良い。
(ノーツなら掲示板の設計とコンテンツが分離されていて、デザイン変更も安心だぜ!!なんて思っている人にとっては物足りないけどね~)
気軽にいろいろできるデータベース接続方式だけど、ちょっと考えないといけない点がある。

1つのサイトコレクションは、複数のコンテンツデータベースにまたいで保存することはできない。一つのコンテンツデータベースには、複数のサイトコレクションを含むことができる。 運用中はあまり気にしなくてもいいんだけど、データベース接続方式って言葉を聞く段階では大きな問題になってることもあるから注意が必要。
例えば、一つのサイトコレクションの作業をしたいのに、1000個のサイトコレクションが同じ一つのコンテンツデータベースに保存されているとき。 別のサーバーで使うにはコンテンツデータベースのコピーを使うので、一つしかいらないのに不要な999個のサイトコレクションもおまけについてくるんだ。 データベースを接続する際には、チェックとかアップグレード処理が動くので、999個分の無駄な処理が動き、当然待ち時間も増えてしまう。
だから、一つのコンテンツデータベースには一つのサイトコレクションが無駄がなくてよいよね。
でも、全部バージョンアップするときは、1000個のコンテンツデータベースのバックアップを取って、接続してって処理が必要になるので、多すぎるのも面倒。1個のコンテンツデータベースのほうが接続時の処理が1度に終わるので、実質こっちのほうが時間は短いのかな?どうなんだろうね。

オンプレミスSharePoint Serverのバージョンアップに備える1

もう経験した?いまだに2007使ってる?
準備は大変だし、待ち時間ながいし、停止時間長いと怒られるし・・・

私はWSS3.0から使い始めて、今は2016だよ。
うん、頑張った。
WSS3.0から2016にバージョンアップした際は、なんて無茶するんだろう?なんて思ったし、スキップしちゃだめだとかその時は思ったけど、結局2010から2016に2013スキップしちゃう自分がいる。実は2019まで行っちゃおうか?なんて本気で考えていたけどね。(さすがにMicrosoft Docsで日本語翻訳されていないタイミングは早すぎると)
正直に言うと2013は運用したことない。あれは2016への通過点だから動けばよかった・・・2010から2013にバージョンアップして何が変わるか細かくは知らないんだよね・・・通過点だからどうでもよかったし~

SharePointのバージョンアップってテータベース接続方式だから、スキップしたとしてもそんなに難易度が上がるってことはなくて、単純に作業量が一気に来るだけなんだよね~
WSS3.0からだと、コンテンツデータベースをSharePoint2010に接続して切断、つぎに2013に接続して切断、さらに2016に接続するだけで作業が終わる。途中のバージョンに合わせて修正する必要がないのでトータル的には作業量は少なく済む。複雑なことしてなければほんと簡単なんだよなぁ~

はっきりいって、メンテナンス中のコンテンツ更新禁止時間に文句が出なければバージョンアップしない理由なんてない。
作業を始めたら終わるまでコンテンツ更新できないんだよね~

だから、とりあえず、テスト環境でバージョンアップ時間を計って、許容範囲か確認したらよいと思うよ。

仮想ホスト管理で困ること

容量固定で作ればよいのでは?
 はい、そうですね、ブルジョアいねっ!!
使った分だけしか占有しないよ!!っていう容量可変VHDさんは礼儀をわきまえ謙虚で素晴らしいです。
ついでに重複除去も動かしましょうかね。
相席大歓迎!!みんなで幸せになろうよ!!
ストレージの仮想化って素晴らしい!!譲り合いの精神、相席、共有、ほんとお前は謙虚でいいやつだ。
って思ってるんですけどね~~
どうせ使わないから物理領域より大きな容量可変VHD作ってもいいよね~
って、はじめは問題なく始めるし、それで結構何年も運用できるんですよ。
物理容量が足らなくなるまでは・・・
仮想化ってホント、トラブルが発生しなければすごく便利。 トラブル出てても、VMには普通に動いているってことも多いし。
リソース不足以外は・・・ リソースについて考え始めると、ほんと答えがなくて困る。
計画的に増強すればいいじゃない?、はいはい、ブルジョアされ!!
リソース不足することには保守契約も更新できない時期に近いんですよ。
保守契約できないサーバーに新品追加してどうすんの。

リソース不足は困るけど、できるだけ利用効率は高めたい。 利用効率高めたいから仮想化してるんだよねぇ~

簡単なんだけど難しい重複除去

アプリケーションの対応可否を気にせずストレージの圧縮ができ、メリットの多い重複除去は、本当に素晴らしい技術です。

ファイル単位の圧縮と異なり、同じファイルが複数保存されているとき、1つのファイル分の容量しか消費しません。ファイル名は異なるけど、同じデータが存在する場合も同じく、一つ分のデータにまとめられるので、ファイル共有サーバーなどでは非常に大きな効果が期待できます。



ただ、いくつか注意が必要です。

1.非対応のアプリケーションが存在する。

冒頭にアプリケーションの対応可否をきにせずと言っておきながら何言っての?って感じですが、アプリケーションのデータを重複除去するとうまくアクセスできない経験がありました。可否を気にせずというのは、HYPER-Vの仮想ディスク保存領域を重複除去するって意味です。こうすれば、VM内では重複除去を意識しない状態になります。

2.急激な大容量保存や編集には対応できない。

空き領域が十分にあれば問題ないし、リアルタイム重複除去機能を持ったH/Wでは問題ありません。Windows標準の重複除去などは、バックグラウンド処理を行うので、重複除去処理されるまでは、そのままのデータが記録されるため、一時的には無圧縮で保存できる領域が必要です。

3.空き領域と使用領域がよくわからない

重複除去を行ったボリュームは、重複除去処理が動くと空き領域が変化します。
データ量を積み上げていくとディスクの容量を超えていることもあります。
もういっぱいだ~と思っても次の日には余裕があるなんてこともあります。

4.ファイルを削除しても空き領域が増えない

重複除去はファイル単位ではなく、データレベルの重複除去を行っているため、100GBのファイルを削除したとしても、そのうち70GBが重複除去領域に保管されていれば、30GBしか解放されません。では、70GBはいつ解放されるのか?というと、ガベージコレクション処理によって、未使用ということが確認された後に解放されるため、ファイルを消しても、消しても、空き領域が全く増えないと感じます。

上の注意点を理解していれば、ほぼ問題なく運用できます。

でも、空き領域が少なくなった時に、ディスク増設できない場合、非常に苦しむことになります。4で上げた空き領域がすぐに増えない問題です。
しかも、利用者からみると、どのファイルが重複除去…

盲目的に見れば安く手に入る

私はOCNモバイルOne音声対応SIM。
パートナーはNTT docomo。

私が機種変をするときは安売りでもない限り定価だ。
エントリーモデルのASUS Zenfone Live(L1)ですら16,000円は必要。
格安SIMの欠点は機種編の際に大きな支出を感じてしまうことです。

トータルのランニングjコストを考慮すると支出は確実に抑えられているはずなんですけどね、機種変では2万円以上をほぼ一括支払いする必要があり、日ごろ2000円程度しか払っていないのですごく目立つんですよね。

そこで考え付いた答えが、パートナーに機種変させて、御下がりをもらう。
誰が使っているのか、使用状況が不明な中古品よりも安心安全。
入手元も利用期間も完ぺきに把握しているのでほんと安心だ。

この度の機種変ではiPhone XR 64GBを選択したわけで、実質負担は35,000円程度なので、
私はiPhone6s 64GBを、パートナーはiPhone XR 64GBの2台を手に入れたと言える。
そして、支払いは無利息24回払いなので、月額負担は1,500円程度となる。
2台機種変するのに1台当たり月額700円なのだ。

安いのだ。
ASUS Zenfone2 LaserからiPhone6sに変えた私は処理能力向上と最新OSによる最高のセキュリティーを手に入れたのである。

しかし、あれだ・・・OS変更はなかなかのストレスである。

3000円で売ったけど、手元には990円

先日買っていただいた3000円の品物の経費を支払うと990円になったって話。

販売手数料 10%(300円)
らくらくメルカリ便 1,500円
振込手数料 210円
残り 990円(出品発送に伴う労務費含む)

どう受け取るかは自由だけど、結構コスト高な取引だなぁ~と。
まぁ、どの方法をとっても似たようなもんですけどね。

粗大ごみが990円に化けて、買った相手は市場価格より安く手に入る。
Win, Winな関係でしかも、メルカリ、ヤマト運輸、銀行にもお金が回る素晴らしい仕組みですね。

そして、なぜ現金化を忘れて没収されるのかがわかりました。
10,000円以下の振込だと210円の手数料が発生する。
出品した合計価格が1万円を超えていれば、1万円まで保留して
210円を浮かせようと考えますよね。

でも、思ったように売れないので時間だけが過ぎていく。

よく考えてある仕組みです。

210円をけちると0円になるのです。
ケチは損です。

メルカリ登録5時間後に発送が完了した。

粗大ゴミの処分って面倒ですよね〜
我が大都会岡山市では持ち込みで無料処分が可能なのですが、
事前に持ち込みゴミの内容と日にちを予約する必要がありちょっと面倒。

って事で、箱も保管していたジュニアシートをメルカリに出品してみました。

オンライン取引はyahooオークション、Amazonマーケットプレイスの引き続き3社目。
今回は評判が高いのか低いのかよくわからないメルカリ。
ちょっとドキドキしながら使ってみました。

登録はSNS始める程度で簡単。
出品も写真を撮って品名とちょっとした説明を入力。
金額は送料と手数料にちょっと上乗せした金額を設定後、出品。
しばらくしたら購入通知が来たので、
近所のヤマト運輸に持ち込んで完了。
後は忘れないように現金化すればすべて終わりですね。

手数料は10%
送料は今回は160サイズの1500円
集荷を依頼しても+30円なので
集荷の方が楽ですね。

箱がある場合、出品してみるのもありですね〜