AWS EC2 から Hyper-V への VM 移行を試してみました – その1

一度クラウド化したものの、利用コストが当初見込みを大きく上回ったりするなどの理由で、「オンプレに戻すことを考えている」というお客様の声をお聞きすることがあります。
「どげんかせんといかん」と勝手に思い込み、クラウド初心者の私が AWS EC2 から Hyper-V への VM 移行を「ActiveImage Protector」の「バックアップ」と「仮想化」機能を使って試してみましたので、その話をしようと思います。

試す前に、AWS EC2、VPC、EBS・・、意味不明な用語について、得意のインターネットからググり何とか理解?して、試行錯誤の末に以下の検証環境を構築しました。

・移行元: AWS EC2インスタンス(Windows Server 2016 (x86_64) t2.micro)
・バックアップ保存先:追加ストレージボリューム(Amazon EBS)
・移行先: Hyper-V(Windows 10 Enterprise)

検証概要は、こんな感じです。
悩みましたが、簡単、確実、且つローコストで移行できる方法ではないかと、いつものごとく勝手に思い込んでいます。

EC2 の移行と書くと凄そうですが、単にバックアップ保存先を EC2 のローカルボリュームに配置することぐらいです。失敗談として、バックアップ保存先の追加ボリュームが別リージョンに作成されていたため、バックアップ検証毎にデータ転送料金「DataTransfer」が加算されていました。

最後に、実際試してみて「ActiveImage Protector」の「バックアップ」と「仮想化」機能を利用すれば、クラウドからオンプレへの移行が簡単にできます。今回の検証方法について、全部一気に書くととても長くなってしまいますので、今後、以下のステップで紹介していきます。

次回は、「AWS EC2インスタンスを構築」についての話をしたいと思います。

・ステップ1:AWS EC2 を構築
・ステップ2:AWS EC2 にバックアップ保存用ボリュームを追加
・ステップ3:AWS EC2 をバックアップ
・ステップ4:バックアップから直接 Hyper-V 上に仮想マシン作成
・ステップ5:移行後の処理

By Oki

[仮想化設定の画面]

[Hyper-V 上に変換された直後の仮想マシン]

続きはこちら:「AWS EC2 から Hyper-V への VM 移行を試してみました – その2

テレワークを始めて気が付く事 – その1

始めに、現在弊社は一部テレワークを導入しておりますが、お客様への対応及びサービスは通常通り行っておりますので、何卒宜しくお願い申し上げます。

*****

テレワーク業務は、主に開発関係の部署で導入されていますが、先日、取引様のお客様がテレワークに入っているとの事で話をしました。
多くのテレワークのパターンとしては、1台のPCを自宅に持ち帰り、会社にVPN接続し、リモートで会社の端末に入ると思いますが、もし「このPCが故障したり、使えなくなったらどうしようか?」と考えると、システム管理者が自宅まで来てくれる訳もなく、自力で復旧となると手慣れたマニアックな社員ばかりではないと思いますので、一般的には深刻な状況となります。

ここで注目されるのが、クライアントPCのバックアップです。
弊社のバックアップソフトウェア ActiveImage Protector であれば操作も簡単で、技術サポートも含まれていますので、お客様の負担も非常に軽くご使用頂けると思います。

シンプルな操作でバックアップと復元が可能です。是非評価版をお試しください。

必要な物は、使用されている PC のバックアップを行う USBHDD などのディスクと弊社の ActiveImage Protector Desktop Edition のみです。

おおよそのご予算は、USB のハードディスクが9,000円以下、そして ActiveImage Protector Desktop Edition が8,400円(税別)ですので、2万円以下で即日ご利用頂けます。
これできめ細かい設定でバックアップが行えますので、テレワークのマシンを安心して運用頂けます。

しかし、用途をもっと絞って、例えば Windows 10 の Update が6月前後に予定されていますが、その Update 後にテレワークの PC が使えなくなったら大変です。
そういった節目節目でバックアップを取って、問題発生時には速やかにシステム復旧が行える製品は?というご要望にお応えした使い捨てのバックアップソリューション(ある意味サブスクリプションより新しい!)「ActiveImage Deploy USB for テレワーク」を間もなくリリースいたします。

次回ブログで製品の詳細をご案内いたしますので、宜しくお願い申し上げます。

By Sato

「DIS ICT EXPO 2020 in 名古屋」に出展しました。

2月14日金曜日のバレンタインデー、ダイワボウ情報システム(株)様主催の「DIS ICT EXPO 2020 in 名古屋」に出展しました。

会場はウインクあいち7Fの展示場でした。

新幹線の止まる名古屋駅から近いのが良いですね。

少し迷っても、そこまで時間がかからずにたどり着けます。

 

私たちは、バックアップツール「ActiveImage Protector 2018 Update」やキッテイングツール「ActiveImage Deploy USB」を展示しました。

 

今回は新型コロナウイルスの問題がある中での開催だったのですが、非常に多くの方が会場まで足を運んでくださっていました。

 

最後になりますが、当日私たちのブースへお立ち寄りいただいた皆様、ありがとうございました。

今年度の「DIS ICT EXPO」は今回でラストになります。

来年度も機会がございましたら、よろしくお願いします。

 

新型コロナウイルスやインフルエンザ等、体調にはお気をつけください。

 

SY

「DIS ICT EXPO 2020 in 関西」に出展しました。

1月29日(水)、ダイワボウ情報システム(株)様主催の「DIS ICT EXPO 2020 in 関西」に出展しました。

 

会場は「グランフロント大阪B2F ナレッジキャピタル コングレコンベンションセンター」です。

大阪は不慣れで、電車を降りてから会場までの道のりで少し迷ってしまうんですよね。

慣れていない土地は、いつも以上に早め早めの行動が大切ですね。

 

私たちはバックアップツール「ActiveImage Protector 2018 Update」やキッテイングツール「ActiveImage Deploy USB」を展示しました。

今回は会場が大阪ということで、来場者の方がとにかく多かったです。

この写真内に並べてあるカタログは、すべてお配りしてしまいました。

 

その疲れからか、帰りの新幹線では2時間30分ノンストップで爆睡してしまいました。

マスクをしていたので、口が開いているなどの間抜けな姿は見られていないはずです。

 

最後になりますが、当日私たちのブースへお立ち寄りいただいた皆様、ありがとうございました。

 

SY

HyperBoot リリース

HyperBootをリリースしました。

HyperBoot とは

HyperBootリリースしました。この製品はActiveImage Protector のユーザー向けに無償配布していたImageBootの後継製品です。

HyperBootはActiveImage Protector のバックアップイメージファイルを直接仮想マシンの仮想ディスクとしてアタッチして起動し使用できます。
通常はバックアップイメージを利用するためには、物理にしろ仮想にしろ実際に復元作業をする必要がありました。ディスクの実体を作成してそこから起動というのが通常の手順です。
これを直接イメージファイルをディスクとしてシステムに認識させることで復元作業をせずに、即時起動できるようにしたのがImageBootでした。

ImageBootでは、VMware Workstation,Player,VirtualBox,ローカルのHyper-Vで利用が可能でしたが、イメージファイルの物理ディスク化のためにローカルマシン上で動作するデバイスドライバを使用していたのでローカルマシン上の仮想環境アプリケーション、ハイパーバイザーのみという制約がありました。

iSCSI対応の技術開発

iSCSIはその名前の通り、インターネットを介したSCSIプロトコルの接続です。
ActiveImage Protector のアップデートにはiSCSI対応の開発が含まれており、完了しました。ActiveImageのバックアップイメージをiSCSIのターゲットとして公開し外部から接続できる技術です。

最近のハイパーバイザーではiSCSIのディスクを仮想ディスクとして扱うことができるので、iSCSI接続のディスクを使った仮想マシンの起動が可能です。もちろん起動するまでにはイニシエーターの設定から始まり、仮想ディスク、仮想マシンの設定、アタッチが必要なので詳しい人ならできる、という状態でした。

そこで、この技術をImageBootでも採用し、GUIを含めてすべて見直して作り直すことにしました。リモートのハイパーバイザーを使ってバックアップイメージからの仮想マシンの直接起動が簡単にできるようになりました。

HyperBootの操作

操作は非常に簡単です。イメージファイルから起動した復元ポイントを選択して起動するだけです。

バックアップイメージファイルを保存したフォルダを指定すると、ソースのコンピューター名(クライアント名)最新の復元ポイントが表示されます。各クライアント毎の復元ポイントを個別に指定することもできます。

HyperBootの起動に使用する仮想マシンの設定を行います。起動確認だけでなくしばらく運用したい場合にはリソースを多めに取っておきます。

 

起動後に変更した部分は差分ファイルとして保存されます。一時的な運用を行った場合でも、その間のデーターを失うことはありません。停止後に再開もできますし、差分ファイルから復元を行えば作業内容も含めて復元できます。

vMotionによるシームレス復旧

さて、せっかく起動したのでそのまま実運用にしてしまいたくなる気持ちが湧いてくるのではないでしょうか?正直なところ起動した状態そのままの運用はイメージと直接やりとりをしているのでリソース的にも速度的に推奨というわけにはいきません。

一方で、イメージファイルから即起動して運用を再開、しばらくしたら自動的に本番環境の復旧が終わっている、そのようなソリューションがあればと思います。

以前からのActiveImage Protectorユーザーなら実際にそうした機能を実現していた  Hyper-V版のReZoom™ it! ライブや、SHR(シームレスホットリストア)機能を思い出すかもしれません。即起動してバックグラウンドで復元を行ってしまう。そのような機能をリモートのハイパーバイザーでも実現できないでしょうか?残念ながら現在のHyperBootではまだそこまでカバーはしていません。

しかし、ESXi限定になりますがvMotionのストレージ移動機能を使えば実現できます。

vMotionは仮想マシン、仮想ディスクの実体を物理ホスト間で仮想マシンを起動したままの状態で移動できるESXiの機能です。ストレージ移動する時に移動元としてiSCSI経由でアタッチしたディスクも対象にできます。つまり、HyperBootで起動した状態でvMotionを使ってストレージを本番環境に移動すれば仮想マシンを復旧したのと同じ状態になりますので、そのまま継続して使用可能になります。

vMotion自体は簡単で、ESXiの管理コンソールから仮想マシンを指定して、移動するだけです。

HyperBootでは内部的にiSCSI接続をしていますが、ActiveImage Protector の最新版ではiSCSI Target 機能があるので汎用的にiSCSIディスクとしてバックアップイメージを利用することができます。また、バックアップ直後に起動を確認するBootCheck機能もあります。起動確認からさらにアプリケーションなどの復元確認を行う必要がある場合にはHyperBootを使うことで運用段階での動作確認が可能です。

ActiveImage Protector セミナー in 台湾高雄

昨年12月、 ActiveImage Protector の台湾の販売代理店 GATI(General Advanced Technology Inc.)が台湾高雄で「予算を50%削減すると同時に、災害復旧パフォーマンスを50%向上させる」と題した ActiveImage Protector のセミナーを開催しました。

本セミナーでは、エンドユーザー様を対象に、ActiveImage Protector のバックアップの運用により、予算目標とパフォーマンス目標の双方を現実的に達成できることについて、事例を踏まえて分かりやすく解説しました。

いつも通り、映画館の劇場ホールを丸ごと貸切り、資料を映しながら迫力あるプレゼンテーションを行いました。

セミナー終了直後、ユーザー様が講演者に質問する様子に皆さまの関心の高さを感じました。

限られた予算内で、バックアップのコストパフォーマンスの良い成果を期待されるお客様は ActiveImage Protector にお任せください!

年末の繁忙期にセミナーにご参加いただきました皆様、ありがとうございました。

YBS

Windows 10 の Updateで仮想マシンが起動しない新年

明けましておめでとうございます。

本年も弊社 ActiveImage シリーズを何卒宜しくお願い申し上げます。

年明けから大阪で挨拶まわりを行っておりましたが、1日勉強会を行いました。

いつものように、HDMIにモニター接続して、今日はP2Vの仮想化についてのご説明をさせて頂こうと思い、VMware Workstation のWindows Server 2019を起動しようとすると、何も起きません。

下図のような画面のままです。

他のゲストOS(Windows 10など)も同様です。

「これでは勉強会は?」と冷や汗をかいているとESXは正常起動。そして、Windows Server 2016 は正常起動だったので、なんとか当初より寂しい環境でしたが、勉強会を進めました。

ホテルに帰ってからPCの再起動など色々としたのですが、もうどうにもなりません。

色々調べていると下記に情報がありました。

https://communities.vmware.com/thread/608636

ふと考えると、昨年の仕事納めの時にWindows Update が動作して、結構な時間をかけてのUpdate 後、仮想マシンを起動していませんでした。

私のマシンは

どうもこの問題のようです。

VMware Workstationの Updateまで、仕事の予定を考えるととても待てません。内容をみると、仮想プリンタと仮想ネットワークアダプタの問題のようです。

ちなみに「OSを再インストールすれば良いか!」と安易に考えて、ISOから新規マシンでインストールを行うと、各種設定後マシンが自動で起動し、通常はコピーが開始されるのですが、ここでも上記の起動しない状況と同じくブラックアウトのままで、強制的に電源をOFFしても結局は VMware 側の exe でつかんだ状態のようで、再起動しても、サービスを落としても、何をしても実際の仮想ディスクを作成したフォルダ内のファイルは削除も出来なくなり、繰り返すとどうにもならない仮想ディスクを大量生成していました。ちなみに起動できなかった OS も電源投入してしまうと、削除など出来なくなりました。

この仮想ディスク関連を削除するには、VMware Workstation を一度アンインストールしてからでないと削除出来ませんでした。VMware 関連のISOもディスクに入っていたので、ライセンスを削除しないで、アンインストールも行いました。

下記は私のケースでの復旧方法です。

〇既存ディスクの起動
Windows 10については起動させない状態で、仮想マシン設定を開きます。

この仮想プリンターを削除します。そして”OK”を押してから仮想マシンの電源を投入するだけです(仮想プリンターを使用したい方の回避方法は、VMware のUpdate 待ちしかないかもしれません)。

Windows 2019についても同じく起動させない状態で、仮想マシン設定を開きます。

同様に仮想プリンターを削除しますが、その時に一緒に現在使用していた仮想ネットワークアダプタを全て削除します。

削除後”OK”を押してその後電源投入を行います。

OS起動後に必要になる仮想ネットワークアダプトを再度作成します。

その後は私のマシンでは正常に動作を行っています。

新規マシンのインストール

その後うっかりして、忘れてまた VMware Workstation を再インストールしたくないので(実際いつも流れでその後も失敗していますが)、OSをインストールするための各種設定後の下図の最後の画面で”完了”を押す前に必ず”ハードウェアをカスタマイズ”をクリックして下さい。

デフォルトでは下図のように仮想プリンターが入ってしまいます。

これを必ず削除してから”完了”をクリックしてインストールを進めてください。

慌てている時はまたやってしまいそうですが、早くVM側のUpdateがされる事を祈るばかりです。

新年早々自分の検証環境のトラブルでの仕事始めとなりました。

同じような環境の皆様も回避して、是非弊社の ActiveImage シリーズを使ってみて頂ければ幸いです。

本年も何卒宜しくお願い申し上げます。

続きを読む…

働き方改革的PCキッティング その11 -最終回-

長きに亘りお読みいただき、ありがとうございます。
働き方改革的PCキッティングは今回が最終回となります。

本ブログをお読みいただきましたエンジニアの方の作業が、少しでも楽になれば本望です
(弊社の Active Image Deploy USBを使用していただければ私は本望です)。

今回は、前回作成した応答ファイルの実行について記述します。

SysprepはC:\Windows\System32\Sysprepにあります。

このフォルダに作成した自動応答ファイルをコピーします。

通常のSysprepの実行は、そのまま管理者権限で起動させたコマンドプロンプトでタイプして実行すれば実行は可能です。その場合は下記のようにUIが表示されます。

今回は作成した応答ファイルを使用しますので、コマンド入力は下記のようになります。

Sysprep /oobe /shutdown /generalize /unattend:Untitled.xml

(“ / ”の前はスペースが入ります)

(上記は作成した応答ファイルの名前はデフォルトとして保存された事を前提としています。)

毎回タイプが面倒なため(入力ミスもあるので)、バッチファイル化する事をお勧めしています。

後は実行してシャットダウンした状態でマスターイメージとして活用可能です。

もちろん弊社のActiveImage Deploy USBで作成したUSBメモリで起動して1クリック下図UIで

「作成」をクリックすれば、マスターイメージはUSBメモリの中に作成されますので、後は展開したいマシンをこのUSBメモリで起動して「復元」を1クリックのみで、それはそれは凄い速さで展開する事が可能となります。
是非下記より評価版をダウンロードして実際にお試しいただければ幸いです。

https://www.netjapan.com/jp/try/activeimage-deploy-usb

追加情報ですが、実際に作り込んでいった方で、キッティングしたPCの初回起動時にバッチを実行したい方は、下記の設定を追記頂ければ簡単に可能です。

Shell-Setupをパス7のoobeSystemに追加して以下のように設定することで、初回起動時のログオン後にプログラムなどを動作させる事が可能となります。

下図のように、名前の通り“ FirstLogonCommands”という項目で設定します。

今まで設定した項目と異なり、Windows システム イメージ マネージャーのプロパティ上で設定は行いません。

この項目の設定方法は、下図のように“ FirstLogonCommands”で右クリックし、
新しいSynchronousCommandの挿入”をクリックします。

動作コマンドラインの入力設定画面が追加されます。(応答ファイルとプロパティ共に)

後はプロパティの”CommandLine”の項目に、動作させたいプログラムなどを記述します。

例えばメモ帳を起動する場合、”c:\windows\notepad.exe”とフルパスで記入します。

説明が必要なければ”Description”の記入は不要です。

Order”は実行の順番です。複数のプログラムを動作させる場合には、上記と同様に右クリックで項目を追加していきます。

追加していくと下図のようになります。

他のプロパティ設定とは異なり、項目追加といった方法となりますので、ご使用方法をご注意ください。

以上で働き方改革的PCキッティングブログは終了となります。

今後は不定期となりますが、また別の情報を掲載する予定です。
来年に向けてはP2V、V2V、クラウドホスティング、他最新の技術情報を営業目線で苦労しながら記述していきたいと思います。

ご質問などはお気軽に法人営業部(corporate@netjapan.co.jp、電話:03-5256-0877)までご一報頂ければ対応させていただきます。

弊社 ActiveImage Protector シリーズ製品を宜しくお願い申し上げます。

By Sato

働き方改革的PCキッティング その10

12月も半ばを過ぎ、師走の慌ただしい時期となりました。インフルエンザの予防注射も接種して、仕事納めまで無事過ごしたいと思う今日この頃です。

さて、今回は自動応答ファイルの設定について記述します。設定方法は人によって異なりますが、あくまで私個人ではこのような設定をしています。

動作自体は「コルタナを飛ばして自動ログインする」までの設定となります。

前回までに項目を5個、応答ファイルに追加していますので、その追加した項目の設定となります。
今回は少し長めのブログとなります。

amd64_Microsoft-Windows-PnpSysprep_neutral (3 generalize)

・DoNotCleanUpNonPresentDevices
Windows セットアップにドライバー構成を保持するようにします。
物理的なスイッチのあるデバイスのON/OFFができる場合、OFFの時にデバイス情報は一般化中に削除される可能性があるので、削除されないようにします。
true “ にする事により検出されないプラグアンドデバイスはインストールされたままとなります。

・PersistAllDeviceInstalls
true “設定にする事により、一般化構成パスの動作中にプラグアンドプレイデバイスがインストール先コンピューターにインストールされたままになるようにしています。
結果として各ドライバーの設定情報を保持します。

amd64_Microsoft-Windows-Security-SPP_neutral (3 generalize)

・SkipRearm
Sysprepの実行回数を減らさないで実行可能にします。
以前は回数が少なかったのですが、現在のWindows 10では1,000回行えますが、一応設定しています。

設定 0 アクティベーション関連のライセンスとレジストリデータは全て削除またはリセットされ、猶予期間タイムもリセットされます。デフォルト設定のようです。

設定 1 アクティベーション関連のライセンスとレジストリデータは全て保存され、リセットはされません。猶予期間タイムもリセットされます。

amd64_Microsoft-Windows-Shell-Setup_neutral (4 specialize)

・ComputerName
”を入力しておくと自動的に設定されます。ここは後で変更するので“”としています。

・CopyProfile
ユーザープロファイルの設定の保持を行います。
カスタマイズしたユーザープロファイルをデフォルトのユーザープロファイルとして使用できます。Windowsはデフォルトのユーザープロファイルをテンプレートとして各新規ユーザーにプロファイルを割り当てます。但し、Sysprepの一般化を実行する時に使用する個別の応答ファイルが必要になる場合もあります。ドメインアカウントは使用できません。

true ”にする事によりカスタマイズを行ってデフォルトのユーザープロファイルを変更します。

・ProductKey
Windows 10のオープンライセンスのアクティベーションキーを入力します。

・TimeZone
日本国内なので、”Tokyo Standard Time”を入力します。

AutoLogon

・Enabled
必ず “ true ”を入力してください。
入れ忘れた場合、Sysprep実行後初回起動でループ状態となり、OSの再インストールになります。

・Username
Auto Logonで使用したいユーザー名を入力します。ここでは「user」としています。

・Password
必要に応じて入力してください(設定した場合のみ)。

amd64_Microsoft-Windows-International-Core_neutral (7 oobeSystem)

・InputLocale
日本の設定は “ 0411:E0010411 “と設定してください。

・SystemLocale
ロケーション設定です。日本は“ ja-JP ”と入力してください。

・UILanguage
Windowsのインターフェイスの言語設定です。日本は“ ja-JP ”と入力してください。

・UserLocale
使用ユーザーのロケーション設定です。日本は“ ja-JP ”と入力してください。

amd64_Microsoft-Windows-Shell-Setup_neutral (7 oobeSystem)

・RegisteredOrganization
登録したい会社名などがあれば入力してください。

・RegisteredOwner
登録したい所有者があれば入力してください。

・TimeZone
一応ここでも日本時間の設定を行います。“ Tokyo Standard Time”を入力します。

OOBE

・HideEULAPage
true”にする事により「Windowsへようこそ」のマイクロソフト ソフトウェアライセンス条項ページを表示しない事を指定します。

・HideLocalAccountScreen
エンドユーザーがOOBE中に表示される管理者パスワード画面を設定する必要があるか指定します。
この設定はWindows Serverの各エディションにのみ適用されます。
false”にするとOOBE中に管理者パスワード画面を非表示にしません。この設定はデフォルト設定です。

・HideOEMRegistrationScreen
これは、OOBE中にOEM登録ページを表示するかどうかを指定します。
この設定を行った場合、oobe.xmlの値に関係なくページはOOBE中に表示されません。
true “にする事によりOOBE中にOEM登録ページを非表示にします。
また1703以降についてはこの設定はWindowsプロビジョニングパッケージでは使用できなくなりました。

・HideOnlineAccountScreens
これはOOBE中にユーザーがサインインを要求されるかを指定します。
主には使用者が電子メールアドレス名をユーザー名として使用したくない場合に使用するようです。
true ”にする事によりOOBE中にサインインページを非表示にします。

・HideWirelessSetupInOOBE
これは「Windowsへようこそ」中に表示される「Wi-Fiネットワークに参加」画面を非表示にするかを指定します。
true ”にする事で「Windowsへようこそ」中に「Wi-Fiネットワークに参加」画面を非表示にします。

・ProtectYourPC
これはExpress設定を以下の目的で使用するかどうか設定します。
連絡先と予定表の詳細を他の関連する入力データと一緒にマイクロソフトに送信する事で音声などの入力をカスタマイズします。
Windowsとアプリが一履歴を含むユーザーのローカライズを要求して、デバイスのエクスペリエンスをパーソライズするようにします。
悪意あるWebコンテンツからの保護をONにしてページ予測を使用してWindowsのブラウザにサイトをプリロードします。観覧履歴がマイクロソフトに送信されます。
マイクロソフトへの問題報告。
設定:1(Express設定をON) 2(Express設定をON) 3(Express設定をOFF)
今回はOFF設定としています。

・SkipMachineOOBE
これは「Windowsへようこそ」をスキップするかどうかを指定します。
MSDNには重要事項として、この設定はWindows 8では推奨されないとかWindows 7ではスキップされるがユーザーアカウント作成、言語、タイムゾーンの設定は構成されないなど一部の機能が機能しない可能性があると記述されています。
true ”にする事により「Windowsへようこそ」をスキップする事を指定します。
但し、この値はテスト目的でのみ使用する事をMSDNでは記述されていますが、今回のテスト環境ではこの項目を設定しないと安定動作できませんでした。
このため今回は設定を行っています。ただこの設定を行う事によりWindows システム イメージ マネージャーのメッセージ欄に下記のワーニングが表示されます。

最後に設定を行っていない項目については全て削除を行います。
削除しない場合、全てエラーとして表示されます。削除後に保存を行い、応答ファイルが完成となります。
下記のようなxmlファイルが出来ていると思います。

いよいよキッティングブログも次回が最終回です。
ブログではわかりにくいと思われた方は、お気軽に法人営業部(corporate@netjapan.co.jp、電話:03-5256-0877)までご連絡頂ければ幸いです。

By Sato

「PowerDay2019 in 静岡」に出展しました

12月13日(金)、ダイワボウ情報システム(株)様主催「PowerDay2019 in 静岡」に出展しました。

会場はグランシップ(静岡県コンベンションアーツセンター) 大ホール・海です。

グランシップ内には、かわいく飾り付けられたクリスマスツリーがありました。

サンタさんが来なくなって久しいですが、クリスマスってテンション上がりますよね。毎年ひそかにサンタさんの来訪を期待しています。

会場の外からは富士山が綺麗に見えました。見た時間帯が少し遅めだったため、暗くて写真には収められず、割愛させていただきます。

搬入日である12日はコールドムーンが綺麗でしたね。写真に収めようと思ったものの、レンズを通すと街灯にしか見えなかったため、これまた割愛です。

展示会で私たちはキッテイングツール「ActiveImage Deploy USB」やバックアップツール「ActiveImage Protector 2018 Update」を展示しました。

とある理由から直近のキッティングに困られているというお話をいくつか伺いました。
そういった方はぜひ弊社の「ActiveImage Deploy USB」を代わりにご使用ください。
もしかしたら元々予定していたものより良いと感じるかもわからないですよ。

評価版は下記のサイトよりお申込みいただけます。
https://www.netjapan.com/jp/try/activeimage-deploy-usb

評価版は「デプロイ用USBメモリ」を作成し、3回まで復元ができます。

 

最後になりますが、「PowerDay2019 in 静岡」が2019年最後の展示会出展となりました。

今年も多くの皆様に弊社ブースへお立ち寄りいただき、ありがとうございました!

SY