How to add a persistent static route to Windows

To view the existing routes,

C:\> ROUTE PRINT

To add a static route,

SYNTAX:
C:\> ROUTE ADD <TARGET> MASK <NETMASK> <GATEWAY IP> METRIC <METRIC COST> IF <INTERFACE>
EXAMPLE:
C:\> ROUTE ADD 10.10.10.0 MASK 255.255.255.0 192.168.1.1 METRIC 1

Note: If there is more than one Network Interface and if the interface is not mentioned, the interface is selected based on the gateway IP.
This Static route gets erased when the system reboots. To avoid this, use the -p (Persistent) switch to the above command:

C:\> ROUTE -P ADD 10.10.10.0 MASK 255.255.255.0 192.168.1.1 METRIC 1

This writes the persistent route to the following Windows Registry key as a string value (REG_SZ):

HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\SERVICES\TCPIP\PARAMETERS\PERSISTENTROUTES

Also, you can write a small batch file with the route commands and add it to the startup folder to add the routes at startup (similar to the startup scripts in Solaris)
For more options like flushing the IP Routing table or to delete, modify IP Routing table entry use the route command with no arguments. This displays the various options for the route command.

C:\> ROUTE

This should help.

VMware ESXi Release and Build Number History

The following listings are a comprehensive collection of the flagship hypervisor product by VMware. All bold versions are downloadable releases. All patches have been named by their release names. Please note that the ESXi hypervisor is available since version 3.5.

vSphere ESXi 6.5

Name Patch Date Build
ESXi 6.5 U1e* ESXi650-201801001 2018-01-09 7526125
ESXi 6.5 Patch 2* ESXi650-201712001 2017-12-19 7388607
ESXi 6.5 Patch 2* (Security only) ESXi650-201712001 2017-12-19 7273056
ESXi 6.5 Express Patch 4 ESXi650-201710401 2017-10-05 6765664
ESXi 6.5 Update 1 ESXi650-update1 2017-07-27 5969303
ESXi 6.5 Update 1 (Security only) ESXi650-update1 2017-07-27 5969300
ESXi 6.5d (vSAN 6.6 Patch) ESXi650-201704001 2017-04-18 5310538
ESXi 6.5 Express Patch 1a ESXi650-201703002 2017-03-28 5224529
ESXi 6.5 Patch 1 ESXi650-201703001 2017-03-09 5146846
ESXi 6.5 Patch 1 (Security Only) ESXi650-201703001 2017-03-09 5146843
ESXi 6.5a ESXi650-201701001 2017-02-02 4887370
ESXi 6.5 GA 2016-11-15 4564106

vSphere ESXi 6.0

Name Patch Date Build
ESXi 6.0 U3d* ESXi600-201801001 2018-01-09 7504637
ESXi 6.0 Patch 6* ESXi600-201711001 2017-11-09 6921384
ESXi 6.0 Patch 6* (Security Only) ESXi600-201711001 2017-11-09 6856897
ESXi 6.0 Express Patch 11 ESXi600-201710301 2017-10-05 6765062
ESXi 6.0 Update 3a (Patch 5) ESXi600-201706001 2017-06-06 5572656
ESXi 6.0 Update 3a (Patch 5) (Security Only) ESXi600-201706001 2017-06-06 5485776
ESXi 6.0 Update 2 (VMSA-2017-0006) ESXi600-201703003 2017-03-28 5251623
ESXi 6.0 Update 1 (VMSA-2017-0006) ESXi600-201703002 2017-03-28 5251621
ESXi 6.0 Express Patch 7a ESXi600-201703001 2017-03-28 5224934
ESXi 6.0 Update 3 ESXi600-update3 2017-02-24 5050593
ESXi 6.0 Update 3 (Security Only) ESXi600-update3 2017-02-24 5047589
ESXi 6.0 Patch 4 ESXi600-201611001 2016-11-22 4600944
ESXi 6.0 Patch 4 (Security Only) ESXi600-201611001 2016-11-22 4558694
ESXi 6.0 Express Patch 7 ESXi600-201610001 2016-10-17 4510822
ESXi 6.0 Patch 3 ESXi600-201608001 2016-08-04 4192238
ESXi 6.0 Patch 3 (Security Only) ESXi600-201608001 2016-08-04 4179598
ESXi 6.0 Express Patch 6 ESXi600-201605001 2016-05-12 3825889
ESXi 6.0 Update 2 ESXi600-update2 2016-03-15 3620759
ESXi 6.0 Update 2 (Security Only) ESXi600-update2 2016-03-15 3568943
ESXi 6.0 Express Patch 5 ESXi600-201602001 2016-02-23 3568940
ESXi 6.0 Update 1b ESXi600-201601001 2016-01-07 3380124
ESXi 6.0 Update 1b (Security only) ESXi600-201601001 2016-01-07 3341439
ESXi 6.0 Express Patch 4 ESXi600-201511001 2015-11-25 3247720
ESXi 6.0 Update 1a ESXi600-201510001 2015-10-06 3073146
ESXi 6.0 Update 1 ESXi600-update1 2015-09-10 3029758
ESXi 6.0 Update 1 (Security only) ESXi600-update1 2015-09-10 3017641
ESXi 6.0b ESXi600-201507001 2015-07-07 2809209
ESXi 6.0b (Security Only) ESXi600-201507001 2015-07-07 2809111
ESXi 6.0 Express Patch 2 ESXi600-201505001 2015-05-14 2715440
ESXi 6.0 Express Patch 1 ESXi600-201504001 2015-04-09 2615704
ESXi 6.0 GA 2015-03-12 2494585

vSphere ESXi 5.5

Name Patch Date Build
ESXi 5.5 U3?* ESXi550-201801002 2018-01-22 7618464
ESXi 5.5 U3g* ESXi550-201801001 2018-01-09 7504623
ESXi 5.5 Patch 11 ESXi550-201709001 2017-09-14 6480324
ESXi 5.5 Patch 11 (Security only) ESXi550-201709001 2017-09-14 6480267
ESXi 5.5 Express Patch 11 ESXi550-201703001 2017-03-28 5230635
ESXi 5.5 Patch 10 (Security only) ESXi550-201612001 2016-12-20 4756874
ESXi 5.5 Patch 10 ESXi550-201612001 2016-12-20 4722766
ESXi 5.5 Patch 9 ESXi550-201609001 2016-09-15 4345813
ESXi 5.5 Patch 9 (Security only) ESXi550-201609001 2016-09-15 4345810
ESXi 5.5 Patch 8 ESXi550-201608001 2016-08-04 4179633
ESXi 5.5 Patch 8 (Security only) ESXi550-201608001 2016-08-04 4179631
ESXi 5.5 Express Patch 10 ESXi550-201602001 2016-02-21 3568722
ESXi 5.5 Express Patch 9 ESXi550-201601001 2016-01-04 3343343
ESXi 5.5 Update 3b ESXi550-201512001 2015-12-08 3248547
ESXi 5.5 Update 3b (Security Only) ESXi550-201512001 2015-12-08 3247226
ESXi 5.5 Update 3a ESXi550-201510001 2015-10-06 3116895
ESXi 5.5 Update 3 ESXi550-update3 2015-09-16 3029944
ESXi 5.5 Update 3 (Security Only) ESXi550-update3 2015-09-16 3029837
ESXi 5.5 Patch 5 re-release ESXi550-201505002 2015-05-08 2718055
ESXi 5.5 Patch 5 (Security Only) ESXi550-201505002 2015-05-08 2702869
ESXi 5.5 Patch 5 (Recalled) ESXi550-201504002 2015-04-30 2702864
ESXi 5.5 Express Patch 7 ESXi550-201504001 2015-04-07 2638301
ESXi 5.5 Express Patch 6 ESXi550-201502001 2015-02-05 2456374
ESXi 5.5 Patch 4 ESXi550-201501001 2015-01-27 2403361
ESXi 5.5 Patch 4 (Security Only) ESXi550-201501001 2015-01-27 2352327
ESXi 5.5 Express Patch 5 ESXi550-201412001 2014-12-02 2302651
ESXi 5.5 Patch 3 ESXi550-201410001 2014-10-15 2143827
ESXi 5.5 Patch 3 (Security Only) ESXi550-201410001 2014-10-15 2093874
ESXi 5.5 Update 2 ESXi550-update2 2014-09-09 2068190
ESXi 5.5 Update 2 (Security Only) ESXi550-update2 2014-09-09 1980513
ESXi 5.5 Patch 2 ESXi550-201407001 2014-07-01 1892794
ESXi 5.5 Patch 2 (Security Only) ESXi550-201407001 2014-07-01 1892623
ESXi 5.5 Express Patch 4 ESXi550-201406001 2014-06-10 1881737
ESXi 5.5 Express Patch 3 ESXi550-201404020 2014-04-19 1746974
ESXi 5.5 Update 1a ESXi550-201404001 2014-04-19 1746018
VMware ESXi 5.5.1 Driver Rollup ESXi550-update1 2014-03-11 1636597
ESXi 5.5 Update 1 ESXi550-update1 2014-03-11 1623387
ESXi 5.5 Update 1 (Security Only) ESXi550-update1 2014-03-11 1598313
ESXi 5.5 Patch 1 ESXi550-201312001 2013-12-22 1474528
ESXi 5.5 Patch 1 (Security Only) ESXi550-201312001 2013-12-22 1474526
vSAN Beta Refresh 2013-11-25 1439689
ESXi 5.5 GA 2013-09-22 1331820

vSphere ESXi 5.1

Name Patch Date Build
ESXi 5.1 Patch 9 ESXi510-201605001 2016-05-24 3872664
ESXi 5.1 Patch 9 ESXi510-201605001 2016-05-24 3872638
ESXi 5.1 Patch 8 ESXi510-201510001 2015-10-01 3070626
ESXi 5.1 Patch 8 (Security Only) ESXi510-201510001 2015-10-01 3021178
ESXi 5.1 Patch 7 ESXi510-201503001 2015-03-26 2583090
ESXi 5.1 Patch 7 (Security Only) ESXi510-201503001 2015-03-26 2575044
ESXi 5.1 Update 3 ESXi510-update3 2014-12-04 2323236
ESXi 5.1 Update 3 (Security Only) ESXi510-update3 2014-12-04 2323231
ESXi 5.1 Patch 6 ESXi510-201410001 2014-10-31 2191751
ESXi 5.1 Patch 6 (Security Only) ESXi510-201410001 2014-10-31 2191354
ESXi 5.1 Patch 5 ESXi510-201407001 2014-07-31 2000251
ESXi 5.1 Patch 5 (Security Only) ESXi510-201407001 2014-07-31 1904929
ESXi 5.1 Express Patch 5 ESXi510-201406001 2014-06-17 1900470
ESXi 5.1 Patch 4 ESXi510-201404001 2014-04-29 1743533
ESXi 5.1 Patch 4 (Security Only) ESXi510-201404001 2014-04-29 1743201
ESXi 5.1 Express Patch 4 ESXi510-201402001 2014-02-27 1612806
ESXi 5.1 Update 2 ESXi510-update2 2014-01-16 1483097
ESXi 5.1 Update 2 (Security Only) ESXi510-update2 2014-01-16 1472666
ESXi 5.1 Patch 3 (Security Only) ESXi510-201310001 2013-10-17 1312874
ESXi 5.1 Patch 3 ESXi510-201310001 2013-10-17 1312873
ESXi 5.1 Patch 2 ESXi510-201307001 2013-07-25 1157734
ESXi 5.1 Patch 2 (Security Only) ESXi510-201307001 2013-07-25 1142907
ESXi 5.1 Express Patch 3 ESXi510-201305001 2013-05-22 1117900
ESXi 5.1 Update 1 ESXi510-update1 2013-04-25 1065491
ESXi 5.1 Update 1 (Security Only) ESXi510-update1 2013-04-25 1063671
ESXi 5.1 Express Patch 2 ESXi510-201303001 2013-03-07 1021289
ESXi 5.1 Patch 1 ESXi510-201212001 2012-12-20 914609
ESXi 5.1 Patch 1 (Security Only) ESXi510-201212001 2012-12-20 911593
ESXi 5.1a ESXi510-201210001 2012-10-24 838463
PP Hot-Patch KB2034796 2012-10-24 837262
ESXi 5.1 GA 2012-09-11 799733

vSphere ESXi 5.0

Name Patch Date Build
ESXi 5.0 Patch 13 ESXi500-201606001 2016-06-14 3982828
ESXi 5.0 Patch 13 (Security Only) ESXi500-201606001 2016-06-14 3982819
ESXi 5.0 Patch 12 ESXi500-201510001 2015-10-01 3086167
ESXi 5.0 Patch 12 (Security Only) ESXi500-201510001 2015-10-01 3021432
ESXi 5.0 Patch 11 ESXi500-201502001 2015-02-26 2509828
ESXi 5.0 Patch 11 (Security Only) ESXi500-201502001 2015-02-26 2486588
ESXi 5.0 Patch 10 ESXi500-201412001 2014-12-04 2312428
ESXi 5.0 Patch 10 (Security Only) ESXi500-201412001 2014-12-04 2216931
ESXi 5.0 Patch 9 ESXi500-201408001 2014-08-28 2000308
ESXi 5.0 Patch 9 (Security Only) ESXi500-201408001 2014-08-28 1979317
ESXi 5.0 Express Patch 6 ESXi500-201407001 2014-07-01 1918656
ESXi 5.0 Patch 8 ESXi500-201405001 2014-05-29 1851670
ESXi 5.0 Patch 8 (Security Only) ESXi500-201405001 2014-05-29 1749766
ESXi 5.0 Patch 7 ESXi500-201401001 2014-01-23 1489271
ESXi 5.0 Patch 7 (Security Only) ESXi500-201401001 2014-01-23 1478905
ESXi 5.0 Update 3 (Security Only) ESXi500-update3 2013-10-17 1311177
ESXi 5.0 Update 3 ESXi500-update3 2013-10-17 1311175
ESXi 5.0 Patch 6 ESXi500-201308001 2013-08-29 1254542
ESXi 5.0 Patch 6 (Security Only) ESXi500-201308001 2013-08-29 1197855
ESXi 5.0 Express Patch 5 ESXi500-201305001 2013-05-15 1117897
ESXi 5.0 Patch 5 ESXi500-201303001 2013-03-28 1024429
ESXi 5.0 Patch 5 (Security Only) ESXi500-201303001 2013-03-28 1022489
ESXi 5.0 Update 2 ESXi500-update2 2012-12-20 914586
ESXi 5.0 Update 2 (Security Only) ESXi500-update2 2012-12-20 912577
ESXi 5.0 Patch 4 (Security Only) ESXi500-201209001 2012-09-27 822948
ESXi 5.0 Patch 4 ESXi500-201209001 2012-09-27 821926
ESXi 5.0 Patch 3 ESXi500-201207001 2012-07-12 768111
ESXi 5.0 Patch 3 (Security Only) ESXi500-201207001 2012-07-12 764879
ESXi 5.0 Express Patch 4 ESXi500-201206001 2012-06-14 721882
ESXi 5.0 Express Patch 3 ESXi500-201205001 2012-05-03 702118
ESXi 5.0 Express Patch 2 ESXi500-201204001 2012-04-12 653509
ESXi 5.0 Update 1 ESXi500-update1 2012-03-15 623860
ESXi 5.0 Update 1 (Security Only) ESXi500-update1 2012-03-15 608089
ESXi 5.0 Patch 2 ESXi500-201112001 2011-12-15 515841
ESXi 5.0 Express Patch 1 ESXi500-201111001 2011-11-03 504890
ESXi 5.0 Patch 1 ESXi500-201109001 2011-09-13 474610
ESXi 5.0 2011-08-24 469512

vSphere ESXi 4.1

Name Patch Date Build
ESXi 4.1 Patch 11 ESXi410-201404001 2014-04-10 1682698
ESXi 4.1 Patch 10 ESXi410-201312001 2013-12-05 1363503
ESXi 4.1 Patch 9 ESXi410-201307001 2013-07-31 1198252
ESXi 4.1 Patch 8 ESXi410-201304001 2013-04-30 1050704
ESXi 4.1 Patch 7 ESXi410-201301001 2013-01-31 988178
ESXi 4.1 Patch 6 ESXi410-201211001 2012-11-15 874690
ESXi 4.1 U3 ESXi410-update3 2012-08-30 800380
ESXi 4.1 Express Patch 3 ESXi410-201206001 2012-06-14 721871
ESXi 4.1 Express Patch 2 ESXi410-201205001 2012-05-03 702113
ESXi 4.1 Patch 5 ESXi410-201204001 2012-04-26 659051
ESXi 4.1 Patch 4 ESXi410-201201001 2012-01-30 582267
ESXi 4.1 U2 ESXi410-update2 2011-10-27 502767
ESXi 4.1 Patch 3 ESXi410-201107001 2011-07-28 433742
ESXi 4.1 Patch 2 ESXi410-201104001 2011-04-28 381591
ESXi 4.1 U1 ESXi410-update1 2011-02-10 348481
ESXi 4.1 Express Patch 1 ESXi410-201011001 2010-11-29 320137
ESXi 4.1 Patch 1 ESXi410-201010001 2010-11-15 320092
ESXi 4.1 GA 2010-07-13 260247

vSphere ESXi 4.0

Name Patch Date Build
ESXi 4.0 Patch 20 ESXi400-201404001 2014-04-10 1682696
ESXi 4.0 Patch 19 ESXi400-201310001 2013-10-24 1335992
ESXi 4.0 Patch 18 ESXi400-201305001 2013-05-30 1070634
ESXi 4.0 Patch 17 ESXi400-201302001 2013-02-07 989856
ESXi 4.0 Patch 16 ESXi400-201209001 2012-09-14 787047
ESXi 4.0 Patch 15 ESXi400-201206001 2012-06-12 721907
ESXi 4.0 Patch 14 ESXi400-201205001 2012-05-03 702116
ESXi 4.0 Patch 13 ESXi400-201203001 2012-03-30 660575
ESXi 4.0 U4 ESXi400-update4 2011-11-17 504850
ESXi 4.0 Patch 12 ESXi400-201110001 2011-10-13 480973
ESXi 4.0 U3 ESXi400-update3 2011-05-05 398348
ESXi 4.0 Patch 11 ESXi400-201104001 2011-04-28 392990
ESXi 4.0 Patch 10 ESXi400-201103001 2011-03-07 360236
ESXi 4.0 Patch 9 ESXi400-201101001 2011-01-04 332073
ESXi 4.0 Patch 8 ESXi400-201009001 2010-09-30 294855
ESXi 4.0 U2 ESXi400-update2 2010-06-10 261974
ESXi 4.0 Patch 7 ESXi400-201005001 2010-05-27 256968
ESXi 4.0 Patch 6 ESXi400-201003001 2010-04-01 244038
ESXi 4.0 Patch 5 ESXi400-201002001 2010-03-03 236512
ESXi 4.0 Patch 4 ESXi400-200912001 2010-01-05 219382
ESXi 4.0 U1 ESXi400-update1 2009-11-19 208167
ESXi 4.0 Patch 3 ESXi400-200909001 2009-09-24 193498
ESXi 4.0 Patch 2 ESXi400-200907001 2009-08-06 181792
ESXi 4.0 Patch 1 ESXi400-200906001 2009-07-09 175625
ESXi 4.0 GA 2009-05-21 164009

ESXi 3.5

Name Version Release Build
ESXe350-201302401-O-SG 3.5 Patch 27 2013-2-21 988599
ESXe350-201206401-O-SG 3.5 Patch 26 2012-06-14 725354
ESXe350-201205401-O-SG 3.5 Patch 25 2012-05-03 702112
ESXe350-201203401-O-SG 3.5 Patch 24 2012-03-09 604481
VMware ESXi 3.5 June 2011 Rollup 3.5 June 2011 Rollup 2011-06-30 391406
ESXe350-201105401-O-SG 3.5 Patch 23 2011-06-02 391406
ESXe350-201012401-O-BG 3.5 Patch 22 2010-12-07 317866
ESXe350-201008401-O-SG 3.5 Patch 21 2010-09-01 283373
ESXe350-201006401-O-SG 3.5 Patch 20 2010-06-24 259926
ESXe350-201003401-O-BG 3.5 Patch 19 2010-03-29 238493
ESXe350-201002401-O-SG 3.5 Patch 18 2010-02-16 226117
ESXe350-200912401-O-BG 3.5 Patch 17 2009-12-29 213532
VMware ESXi 3.5 Update 5 3.5 U5 2009-12-03 207095
ESXe350-200910401-I-SG 3.5 Patch 16 2009-10-16 199239
ESXe350-200908401-I-BG 3.5 Patch 15 2009-08-31 184236
ESXe350-200907401-I-BG 3.5 Patch 14 2009-07-30 176894
ESXe350-200906401-I-BG 3.5 Patch 13 2009-06-30 169697
ESXe350-200905401-I-BG 3.5 Patch 12 2009-05-28 163429
ESXe350-200904401-I-SG 3.5 Patch 11 2009-04-29 158874
VMware ESXi 3.5 Update 4 3.5 U4 2009-03-30 153875
ESXe350-200903411-I-BG 3.5 Patch 10 2009-03-20 153480
ESXe350-200901401-I-SG 3.5 Patch 9 2009-01-30 143129
ESXe350-200811401-I-SG 3.5 Patch 8 2008-12-02 130755
VMware ESXi 3.5 Update 3 3.5 U3 2008-11-06 123629
ESXe350-200809401-I-SG 3.5 Patch 7 2008-10-03 120505
ESXe350-200808501-I-SG 3.5 Patch 6 2008-09-18 113338
VMware ESXi 3.5 Update 2 (reissued) 3.5 U2 2008-08-13 110271
ESXe350-200807812-I-BG 3.5 Patch 5 2008-08-12 110180
VMware ESXi 3.5 Update 2 (timebombed) 3.5 U2 2008-07-25 103909
ESXe350-200805501-I-SG 3.5 Patch 4 2008-06-03 94430
ESXe350-200804401-O-BG 3.5 Patch 3 2008-04-30 85332
VMware ESXi 3.5 Update 1 3.5 U1 2008-04-10 82664
ESXe350-200802401-I-BG 3.5 Patch 2 2008-03-10 76563
ESXe350-200712401-O-BG 3.5 Patch 1 2008-01-17
VMware ESXi 3.5 Initial Release 3.5 2008-01-10 70348
VMware ESXi 3.5 First Public Release 3.5 2007-12-31 67921

The Spectre and Meltdown situation

170px-SPECTRE_Logo
Many blog posts have been written about the two biggest security vulnerabilities discovered so far in 2018. In fact, we are talking about three different vulnerabilities:

  • CVE-2017-5715 (branch target injection)
  • CVE-2017-5753 (bounds check bypass)
  • CVE-2017-5754 (rogue data cache load)

CVE-2017-5715 and CVE-2017-5753 are known as “Spectre”, CVE-2017-5754 is known as “Meltdown”. If you want to read more about these vulnerabilities, please visit spectreattack.com & meltdownattack.com
Multiple steps are necessary to be protected, and all necessary information are often repeated, but were distributed over several websites, vendor websites, articles, blog posts or security announcements.
How to protect yourself against these attacks
Two (apparent simple) steps are necessary to be protected against these vulnerabilities:

  1. Apply operating system updates
  2. Update the microcode (BIOS) of your server/ workstation/ laptop

If you use a hypervisor to virtualize guest operating systems, then you have to update your hypervisor as well. Just treat it like an ordinary operating system. Also if your using vendor created software appliances that may be based on OS distributions like CentOS then those need to be protected also.
Sounds pretty simple, but it’s not. I will focus on three vendors in this blog post:

  • Microsoft
  • Linux
  • VMware

Let’s start with Microsoft. Microsoft has published the security advisory ADV180002  on 01/03/2018.
Microsoft Windows (Client)
The necessary security updates are available for Windows 7 (SP1), Windows 8.1, and Windows 10. The January 2018 security updates are ONLY offered in one of theses cases (Source: Microsoft):

  • An supported anti-virus application is installed
  • Windows Defender Antivirus, System Center Endpoint Protection, or Microsoft Security Essentials is installed
  • A registry key was added manually

 

Update
Windows 10 (1709) KB4056892
Windows 10 (1703) KB4056891
Windows 10 (1607) KB4056890
Windows 10 (1511) KB4056888
Windows 10 (initial) KB4056893
Windows 8.1 KB4056898
Windows 7 SP1 KB4056897

Please note, that you also need a microcode update! Reach out to your vendor.
Windows Server
The necessary security updates are available for Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2016 and Windows Server Core (1709). The security updates are NOT available for Windows Server 2008 and Server 2012!. The January 2018 security updates are ONLY offered in one of theses cases (Source: Microsoft):

  • An supported anti-virus application is installed
  • Windows Defender Antivirus, System Center Endpoint Protection, or Microsoft Security Essentials is installed
  • A registry key was added manually

 

OS Update
Windows Server, version 1709 (Server Core Installation) KB4056892
Windows Server 2016 KB4056890
Windows Server 2012 R2 KB4056898
Windows Server 2008 R2 KB4056897

After applying the security update, you have to enable the protection mechanism. This is different to Windows Windows 7, 8.1 or 10! To enable the protection mechanism, you have to add three registry keys:

VMware has published two VMware Security Advisories (VMSA):

VMware Workstation Pro, Player, Fusion, Fusion Pro, and ESXi are affected by CVE-2017-5753 and CVE-2017-5715. VMware products seems to be not affected by CVE-2017-5754. On 09/01/2017, VMware has published VMSA-2018-0004, which also addresses CVE-2017-5715. Just to make this clear:

  • Hypervisor-Specific Remediation (documented in VMSA-2018-0002)
  • Hypervisor-Assisted Guest Remediation (documented in VMSA-2018-0004)

Before you apply any security updates, please make sure that you :

  • Deploy the updated version of vCenter listed in the table (only if vCenter is used).
  • Deploy the ESXi security updates listed in the table.
  • Ensure that your VMs are using Hardware Version 9 or higher. For best performance, Hardware Version 11 or higher is recommended.

For more information about Hardware versions, read VMware KB article 1010675.
VMSA-2018-0002

OS Update
ESXi 6.5 ESXi650-201712101-SG
ESXi 6.0 ESXi600-201711101-SG
ESXi 5.5 ESXi550-201709101-SG

VMSA-2018-0004

OS Update
ESXi 6.5 ESXi650-201801401-BG, and
ESXi650-201801402-BG
ESXi 6.0 ESXi600-201801401-BG, and
ESXi600-201801402-BG
ESXi 5.5 ESXi550-201801401-BG
vCenter 6.5 6.5 U1e
vCenter 6.0 6.0 U3d
vCenter 5.5 5.5 U3g

All you have to do is:

  • Update your vCenter to the latest update release, then
  • Update your ESXi hosts with all available security updates
  • Apply the necessary guest OS security updates and enable the protection (Windows Server)

Make sure that you also apply microcode updates from your server vendor!
 

QNAP TS-431X NAS with 10G SFP+

QNAP today announced the new TS-431X NAS with a built-in 10GbE SFP+ port. It is powered by a dual-core AnnapurnaLabs, an Amazon company Alpine AL-212 1.7 GHz processor and 2GB/8GB DDR3 RAM (upgradable to 8GB). The TS-431X delivers up to 956 MB/s read speed with 10GbE.
266_1
Along with its application-aware design and abundant productive features including containerized virtualization, centralized email management, a private-cloud-based note-taking tool, and Virtual JBOD, the 10GbE-ready TS-431X is a perfect NAS for small and midsize businesses looking for backup, restoration, private cloud, and higher bandwidth for rigorous data processing.
The integrated 10GbE SFP+ port enables exceptional throughput for intensive data transfer, and fast backup and restoration for an ever-growing amount of data.
“Designed to solve more complex and demanding applications in today’s IT environments, the TS-431X is well suited for organizations that have budget constraints but require high bandwidth to tackle inefficiencies.” said Dan Lin, Product Manager of QNAP.
The TS-431X features Container Station that integrates LXC and Docker® lightweight virtualization technologies, enabling unlimited containerized applications. It offers the innovative QIoT Containers to store Internet of Things (IoT) data, and helps organizations boost IoT-based microservices and modernize legacy applications to drive more business opportunities.
The TS-431X is an all-in-one NAS supporting not only essential cross-platform file sharing, backup, restoration, and security, but also exclusive productivity apps. QmailAgent allows users to centrally manage multiple email accounts from popular email services and IMAP servers; Notes Station provides an online note-taking tool enabling collaborative writing; Qsync enables cross-devices file synchronization and team folders sync; and the powerful Qsirch full-text search engine helps quickly find files on the NAS. The TS-431X also supports VPN server and VPN client, IP surveillance system, and VJBOD (Virtual JBOD) to expand the storage capacity of other QNAP NAS.
Key specifications

    • TS-431X-2G: 2GB DDR3 RAM (2GB x1)
    • TS-431X-8G: 8GB DDR3 RAM (8GB x1)

4-bay tower model; AnnapurnaLabs, an Amazon company Alpine AL-212 1.7 GHz dual-core processor, hardware-accelerated encryption engine; hot-swappable 2.5″/3.5″ SATA 6Gbps HDD or SSD; 1 x 10 Gigabit SFP+ port, 2 x Gigabit RJ45 ports; 3 x USB 3.0 port, Kensington security slot

Openstack – Configuring for LVM Storage Backend

The volume service is able to make use of a volume group attached directly to the server on which the service runs. This volume group must be created exclusively for use by the block storage service and the configuration updated to point to the name of the volume group.
The following steps must be performed while logged into the system hosting the volume service as the root user:
  1. Use the pvcreate command to create a physical volume.
    # pvcreate DEVICE
      Physical volume "DEVICE" successfully created
    Replace DEVICE with the path to a valid, unused, device. For example:

    # pvcreate /dev/sdX
  2. Use the vgcreate command to create a volume group.
    # vgcreate cinder-volumes DEVICE
      Volume group "cinder-volumes" successfully created
    Replace DEVICE with the path to the device used when creating the physical volume. Optionally replace cinder-volumes with an alternative name for the new volume group.
  3. Set the volume_group configuration key to the name of the newly created volume group.
    # openstack-config --set /etc/cinder/cinder.conf \
    DEFAULT volume_group cinder-volumes
    The name provided must match the name of the volume group created in the previous step.
  4. Ensure that the correct volume driver for accessing LVM storage is in use by setting the volume_driverconfiguration key to cinder.volume.drivers.lvm.LVMISCSIDriver.
    # openstack-config --set /etc/cinder/cinder.conf \
    DEFAULT volume_driver cinder.volume.drivers.lvm.LVMISCSIDriver
The volume service has been configured to use LVM storage.

Openstack Liberty Error: Unable to retrieve volume limit information.

After an Openstack Liberty deployment  you may encounter the following error: Error: Unable to retrieve volume limit information. OR Danger: There was an error submitting the form. Please try again.
unable to retreive size limit
These errors are a result of a miss-configuration within CINDER, to resolve this all you need to do is edit the ‘/etc/cinder/cinder.conf‘ file and make sure the following two lines exist

[keystone_authtoken]
auth_uri = http://keystone_ip:5000
auth_url = http://keystone_ip:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = services
username = cinder
password = [ccinder password] <- find from answer file. password is stored in CONFIG_CINDER_KS_PW

After you had verified or added the lines you will need to restart the cinder services by running:

# service openstack-cinder-api restart
# service openstack-cinder-backup restart
# service openstack-cinder-scheduler restart
# service openstack-cinder-volume restart

Using multiple external networks in OpenStack Neutron

I haven’t found a lot of documentation about it, but basically, here’s how to do it. Lets assume the following:

  • you start from a single external network, which is connected to ‘br-ex’
  • you want to attach the new external network to ‘eth1’.

In the network node (were neutron-l3-agent, neutron-dhcp-agent, etc.. run):

  • Create a second OVS bridge, which will provide connectivity to the new external network:
ovs-vsctl add-br br-eth1
ovs-vsctl add-port br-eth1 eth1
ip link set eth1 up
  • (Optionally) If you want to plug a virtual interface into this bridge and add a local IP on the node to this network for testing:
ovs-vsctl add-port br-eth1 vi1 – set Interface vi1 type=internal
ip addr add 192.168.1.253/24 dev vi1 # you may adjust your network CIDR, or set your system configuration to setup this at boot.
  • Edit your /etc/neutron/l3_agent.ini , and set/change:
gateway_external_network_id =
external_network_bridge =

This change tells the l3 agent that it must relay on the physnet<->bridge mappings at /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini it will automatically patch those bridges and router interfaces around. For example, in tunneling mode, it will patch br-int to the external bridges, and set the external ‘q’router interfaces on br-int.

  • Edit your /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini to map ‘logical physical nets’ to ‘external bridges’
bridge_mappings = physnet1:br-ex,physnet2:br-eth1
  • Restart your neutron-l3-agent and your neutron-openvswitch-agent
service neutron-l3-agent restart
service neutron-openvswitch-agent restart

At this point, you can create two external networks (please note, if you don’t make the l3_agent.ini changes, the l3 agent will start complaining and will refuse to work)

neutron net-create ext_net –provider:network_type flat –provider:physical_network physnet1 –router:external=True
neutron net-create ext_net2 –provider:network_type flat –provider:physical_network physnet2 –router:external=True

And for example create a couple of internal subnets and routers:

# for the first external net
neutron subnet-create ext_net –gateway 172.16.0.1 172.16.0.0/24 – –enable_dhcp=False # here the allocation pool goes explicit…. all the IPs available..
neutron router-create router1
neutron router-gateway-set router1 ext_net
neutron net-create privnet
neutron subnet-create privnet –gateway 192.168.123.1 192.168.123.0/24 –name privnet_subnet
neutron router-interface-add router1 privnet_subnet
# for the second external net
neutron subnet-create ext_net2 –allocation-pool start=192.168.1.200,end=192.168.1.222 –gateway=192.168.1.1 –enable_dhcp=False 192.168.1.0/24
neutron router-create router2
neutron router-gateway-set router2 ext_net2
neutron net-create privnet2
neutron subnet-create privnet2 –gateway 192.168.125.1 192.168.125.0/24 –name privnet2_subnet
 neutron router-interface-add router2 privnet2_subnet

Setting Up a Flat Network with Openstack Neutron

This setup will allow the VMs to use an existing network. In this example, eth2 is connected to this pre-existing network (192.168.1.0/24) that we want to use for the OpenStack VMs.
All the configuration is done in the node dedicated to Nova Networking.
1. Set up the Open vSwitch bridge:

# ovs-vsctl add-br br-eth2
# ovs-vsctl add-port br-eth2 eth2

2. Set up /etc/network/interfaces (node’s IP is 192.168.1.7):

auto eth2
iface eth2 inet manual
up ifconfig $IFACE 0.0.0.0 up
up ip link set $IFACE promisc on
down ip link set $IFACE promisc off
down ifconfig $IFACE down
auto br-eth2
iface br-eth2 inet static
address 192.168.1.7
netmask 255.255.255.0

3. Tell Open vSwitch to use the bridge connected to eth2 (br-eth2) and map physnet1 to it /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini:

[ovs]
network_vlan_ranges = physnet1
bridge_mappings = physnet1:br-eth2

4. Tell Neutron to not to use the metadata proxy in /etc/nova/nova.conf (otherwise you get a HTTP 400 when querying the metadata service):

service_neutron_metadata_proxy=false

Note that the metadata service is managed by Neutron as usual via the neutron-metadata-agent service anyway.
5. Create the network telling to use the physnet1 mapped above to br-eth2:

# neutron net-create flat-provider-network --shared  --provider:network_type flat --provider:physical_network physnet1

6. Create the subnet:

# neutron subnet-create --name flat-provider-subnet --gateway 192.168.1.5 --dns-nameserver 192.168.1.254  --allocation-pool start=192.168.2.100,end=192.168.2.150  flat-provider-network 192.168.2.0/24

That’s it. Now VMs will get an IP of the specified range and will be directly connected to our network via Open vSwitch.

Fixing Openstack Kilo Horizon Re-login issue

Fixing Horizon Re-login issue

There is an issue in OpenStack Kilo with re-login because of a bad cookie session. Here is how to fix the issue.

#vi /etc/openstack-dashboard/local_settings
AUTH_USER_MODEL = 'openstack_auth.User'

Disaster Recovery as a Service: Ten steps to success


Disaster recovery is becoming top of mind for many CIOs. Understanding the success criteria to make the disaster recovery journey of your own organization smooth and successful is critical, but the path to getting there can be difficult.
Follow the ten key steps below, to guide you on the right path to success.

  1. Understand why disaster recovery is important to your business, and what your specific disaster recovery requirements are.

The first key step is understanding why you are looking for a disaster recovery solution for your business, and what your requirements are- from a disaster recovery perspective as well as for the solution in need. Running a Business Impact Analysis (BIA) will assist in the impact of a disruption to your business and will also help expose the effect of such disruption to your reputation including the effect of any loss of data or loss of staff, the BIA is very much the building block and foundation of your disaster recovery planning and knowing what the business impact to outages is probably the most important aspect in defining the answer to the “why” question. Knowing the business impact will not only drive the Service Level Agreements (SLAs) for the business processes they will also assist the disaster recovery plan to minimise any prolonged outages which could be derived from human error during the recovery process. If these aspects are missing and haven’t been thought of yet then running a Business Impact Analysis should be the first thing that you do and will put you in good stead as you move forward.
An additional aspect of the disaster recovery process is to understand your Recovery Point Objective (RPO), Recovery Time Objective (RTO). From a SLA perspective, think about the amount of time and data loss your business can incur. Zero data loss is obviously ideal, but this can exponentially drive up the cost of the solution. Having a limit to the data loss that can be incurred by your business based on the business service is realistic. Both the time and data loss windows will translate to your RTO and RPOs respectively.
Additionally, does your business require adherence to any regulatory compliance or operating rules? For example, do you need to provide proof of a quarterly or yearly disaster recovery test?  Disaster recovery testing is important, and there are a lot of factors to take into consideration here. What kind of replication technology would you choose – expensive hardware-based replication or host-based or even replication to the cloud. What you choose is based on various factors including cost, business policies, SLA requirements, and importantly environmental factors.  For instance, if your data center is located in an area which gets affected by floods, then your disaster recovery location needs to be in a separate geographic area or even in the cloud.

  1. Should you build your own or buy off the shelf?

The next step is driven by how much investment you either want to make operationally or in capital expenditure. You probably have already invested quite heavily into infrastructure at your primary data center location – things such as server hardware, virtualization technologies and storage. You could take a simple approach and invest in another physical data center for disaster recovery, but this would lead to the expense of not only double software / hardware infrastructure costs but also additional physical location costs. A more savvy approach would be to utilize a vendor to supply disaster recovery services at a fraction of the cost of running dual locations. Keep in mind that choosing the right vendor is important too. You will want to look for a leader in the managed disaster recovery services space that has years of credible experience.

  1. Understand the difference between disaster recovery as-a-service and backup and recovery as-a-service.

Understand that disaster recovery and backup are different ball games. While backup is a necessary part of a business continuity strategy, it lends itself to SLAs of hours to days. On the other hand, disaster recovery is better suited to SLA requirements in minutes to hours. Based on the business uptime and data loss requirements specific to a business service, your business would deploy a disaster recovery solution for your business-critical applications, while backup would be sufficient for those non-critical business services which can take some downtime.  Choose a disaster recovery as-a-service solution that can protect your entire estate or at least the critical elements of it that drive your business. This includes physical and virtual systems, as well as the mix of different OSs that typically are run within enterprise businesses today. The disaster recovery as-a-service solution that you choose should also be able to provide you with the ability to run your systems within their cloud location for a period of time, until you can get your infrastructure back up and running and transfer services back to your primary site.

  1. Choose the right Cloud Hypervisor.

It may seem like an easy decision to make- you would seek a vendor that runs the same hypervisor on the backend as you are on your primary site, but keep in mind this is not a necessity.  If you are using VMware vSphere or Microsoft Hyper-V then running these type of hypervisors in the cloud is going to incur some additional licensing costs in a DR solution. Another thing to think about is whether you really need all the bells and whistles when you’ve invoked disaster recovery. Most of your time is going to be taken up with getting services up and running back at your own location as quickly as possible, so maybe not. What you basically need is a hypervisor to host your systems that provides the basic performance, scale and resilience you require. A more cost-efficient stance would be to utilise a KVM-based hypervisor running within OpenStack. This ticks the boxes in terms of enterprise ready and best of all, the service costs should yield a better ROI than those running proprietary hypervisor technologies, saving your business considerable money.

  1. Plan for all business services that need to be protected, including multi-tier services

Now were getting down to the nitty-gritty details. The business services that need to be protected will be primarily driven by the SLAs that brought you down this path. Keep in mind that you capture all operating system types that these business services are running on and also think about how you handle any physical systems that have not yet been virtualized. Moving virtualized applications to the cloud is an easy process, as these are already encapsulated by the hypervisor in use. But pure physical business applications are another matter altogether.  It is not impossible to move physical application data to the cloud, but when it comes to a failback scenario, if the services you select does not have this capability, then you are a sitting duck. This is especially important to keep in mind in the case where a complete outage has occurred and a rebuild is needed. Another thing to think about is when your business services or applications are started in the cloud- can you start or stop these systems in a particular order if a business service is made of different processes, such as a multi-tier application, and also inject manual steps within your failover plan if so required? Controlling multi-tier business applications that span across systems is going to be a high priority, not only while invoking disaster recovery but also when you’re performing a disaster recovery test.

  1. Plan for your RTOs, RPOs, Bandwidth, Latency and IOPs

Understanding how you can achieve your Recovery Point Objective (RPO), Recovery Time Objective (RTO), as well as the IO load of virtual machines, and the peaky nature of writes through the business day within your systems, this data will help you understand what your required WAN bandwidth should be. Determine whether your disaster recovery service vendor can guarantee these RTOs and RPOs, because every additional minute or hour that your business is down as defined by the Business Impact Analysis is going to cost you. If you aim for RPO of 15 minutes or less, then your bandwidth to the cloud needs to be big enough to cope with extended periods of heavy IO within your systems. If your RTO is something like 4 hours, then you need to know if your systems can recover within that time period, keeping in mind that other operations too need to be managed, such as DNS and AD/LDAP updates including any additional infrastructure services that your business needs.

  1. Avoid vendor lock-in while moving data to the cloud

Understanding how your data will be sent to the cloud provider site is important. A solution that employs VMware vSphere on-premises and in the cloud limits you to a replication solution that works only for virtualized systems with no choice of protecting physical OS systems. This may seem acceptable at the time, but you will be locked into this solution and switching DR providers in the future may be difficult.  Seeking a solution that is flexible and can protect all types of major virtualization platforms as well as physical OS gives you the flexibility of choice for the future.

  1. Run successful disaster recovery rehearsals without unexpected costs

Rehearsals or exercises are probably the most important aspect of any disaster recovery solution. Not having an automated disaster recovery rehearsal process that you test on a regular basis can leave your business vulnerable. Your recovery rehearsals should not affect your running production environment. Any rehearsal system should run in parallel albeit within a separate network VLAN, but still have some type of access to infrastructure services such as AD, LDAP and DNS etc. so that full disaster recovery testing can be carried out. Once testing is complete, it is essential that the solution include a provision to easily remove and clean up the rehearsal processes.

  1. How long can you stay in the cloud?

For a moment let’s imagine that the unthinkable has happened, and you have invoked disaster recovery to your cloud service provider. The nature of the outage at your primary location will dictate the length of time you will need to keep your business applications running on your service providers’ infrastructure. It is imperative that you are aware of any clauses within your contract that pertain to length of time you can keep your business running on the cloud providers’ site. There is also a big pull to get enterprises to think about running in the cloud and staying there, but this is a big decision to make. Performance of the systems is going to be one metric to poll against, as is performance of storage, or more precisely the quality of service of the storage that the cloud vendor will provide. On the whole, it makes sense to get back into your own infrastructure as quick as possible, since it is custom built to support your business.

  1. How easy is it to failback business services to your own site?

Getting your data back or reversing the replication data path is going to be important especially as you don’t want to affect your running systems within the cloud by injecting more downtime! Rebuilding your infrastructure is one aspect that needs to be meticulously planned. Any assistance that the solution itself can provide to make this process smoother is a bonus. Your on-premises location is going to need a full re-sync of data from the cloud location which may take some time, so the solution should be able to handle a two-step approach to failback- the re-sync should happen in one operation and once complete, the process to switch back your systems can be done at a time that suits your business.
Success, you’re now armed to create a robust business continuity plan.
Follow the steps above to gain an understanding of what’s needed to be successful on your disaster recovery as a service journey, and use them as checkpoints while developing you own robust business continuity plan for your business.