The Division and delta 20010186

There is no doubt that if you search on The Division for the Mike or Delta error messages you will uncover a sordid history of unhappy users that began with the beta and continues.

My son recently invested in this game only to pop it into the Xbox to be greeted by the "delta 20010186" error.

tl:dr

1. enable uPNP
2. If you have a router behind your modem, put your modem in bridge mode
3. Rerun the Xbox multiplayer network test (see the link below) - UBISoft requires this to test as 'open'

The long winded explanation:

If you search on this you will find all kinds of guessed at solutions.  From punching port forwarding rules in your firewall to putting your Xbox wide open for attack in a DMZ (seriously, these are the suggestions from UBISoft for Xbox connectivity)

Considering the number of folks that run into this issue, I really don't think UBIsoft understands it.

After thinking about this and spending hours troubleshooting, my conclusion is this: UBISoft blocks the game working if there is any reduction in the multi-player experience at all.

If you read the Xbox network descriptions, there should be grades in the experience where only certain features of the game don't function if the connectivity status is reduced from the full set.  And I can only speculate that UBISoft chose to not follow this guideline (could be by choose or ignorance - the result is the same).

There is a mysterious black box type issue on the Xbox side that puts the pieces together.
It is rooted in the output of the Xbox multiplayer network test and the resulting "NAT type".
This is not a setting that any human can impact, nor any resetting, cryptic combinations of movement through the settings menus or anything else can reliably impact.

From what I can tell, there are a couple issues going on here.

1. There is an expectation that uPNP is enabled on your router.

The multiplayer mode requires communication back to your Xbox. 
This is why there are port forwarding rules being suggested, and DMZ placement.  If uPNP is not available or not working, this this would solve that issue.

Adding to this is claims that I uncovered that stated that Xbox historically had issues with properly making the uPNP router when it is set to 'InstantOn' power mode.
Again, uPNP not working for a different reason.

Wrap all of these together and you have a combination of things that all impact connectivity back and the Xbox test for multiplayer connectivity puts you in the Moderate or Severe NAT bucket.

2. Beware the double NAT

No matter the setting on your router, if you have put yourself into a double NAT configuration, you will never be tested as 'open' by Xbox.

What is this double NAT?  It is when you hop through two IP address changes on your end of the network.
Frequently a double NAT happens in the IT world to isolate front end web servers or to further protect the corporate network by using two firewalls instead of one.

For the home network, the first NAT would be between your ISP (Comcast, ATT, etc.) and you - your cable modem (or FIOS modem, 'the modem').  The ISP network IP address range is converted once.
If you go straight from your modem to a switch, you are probably good.

The second NAT happens when you put a router behind your cable modem.  Thus you end up traversing another IP address change.  Thus a second IP change.  The key here is that the public side of this second NAT is private behind the first firewall of the modem.

This looks like this:  - modem - - router -
The problem is that any modifications you make to your router get trapped in this container .
Not even port forwarding or DMZ will work properly here unless your cable modem supports uPNP or does not offer a firewall at all ( most give a firewall and default you into this first NAT ).

The things here, simply put your model into 'bridge' mode.
What this does is turn off this first NAT, and your router gets the public side IP from your ISP instead of your cable modem getting it.
The impact here is that for most of us, this means only ONE device can plug into the modem.  As you only get one IP of the ISP network.

If you cannot put your modem into bridge mode, put attach your Xbox directly to the modem (using a switch to go around your router).
I am always assuming that there is still some network protection here, at least a basic firewall.  As just about anything can be hacked these days.



I always want folks to understand how things work, how things function and to tie as much as what I uncover together in a cohesive way.  That is what I have attempted to do here.

I hope it helps some folks, or solves the problem for others.
It is very frustrating to bring a new game home ($80 - $100) only to have it not work (fail to load) at all.  From the number of passed customers on the web, I am not alone.

PowerShell to the Philips Hue API

If you have been to HPE Discover London 2015, Aruba Atmosphere 2016, CeBIT 2016 or you are going to Citrix Synergy 2016 you will have an opportunity to experience the Collaborate Cube(d).

https://twitter.com/hpecollaborate

I have been working with the Cube (making it do its song and dance) and related technologies for nearly two years.

This is an IoT thing.  But what we are driving and the place we are operating is not what most folks thing of as IoT.
This is about taking context (a person, a physical place, the capabilities of a space, and what is relevant at this moment in time) and tying them all together into a set of context specific actions (capabilities, events, controls - call it what you will).

The actions are relevant to this time and place.

One of the actions in the Cube is setting lights around the glass enclosure to red (the room is busy) or green (the room is available).

This sounds pretty simple on the surface.  You hook up a Philips Hue then you link it in, then you send some commands.  Actually, it is rather simple.  Except one part that is not entirely obvious to most folks (that aren't makers nor developers), and that is getting that first connection in the first place.

In helping to set the Cube up at three venues now, the Hue connection still seems to be one of the more complex things.  Especially when you Hue is brand new (which of course it is at each show :-S  ).

So, I have a little PowerShell script that will give you what you need to:

1. create a valid user in your local Hue bridge
2. get the information you need to connect to that

Of course I am using Octoblu to control the Hue.  Why wouldn't I?  There are some decent instructions for getting things set up. (see Step 4, then instead of 3 come back here, then 5).
But they send you off to an API document to sort out the one critical getting started piece, getting connected.  And then Philips hides their API guide behind a registration gate.  Double whammy.  Too much effort.  Walk away.

Here is my script, with comments, to get you started.
And after you get hooked up, there is most likely enough guidance in this script for you to simply play with the Philips Hue API.  ;-)

You can copy, save, and run this script and it should do everything you need.

# Associate your Hue Bridge with Octoblu.
# These are the setup things you need to do.

# find the Hue on your local network - this assumes you have only one
$hueIp = Invoke-RestMethod -URI https://www.meethue.com/api/nupnp
$ip = $hueIp[0].internalipaddress

$gatebluName = Read-Host -Prompt "Enter the name of your Gateblu"

Do {
    if ( !$hueUser ) {
        Write-Host -ForegroundColor Black -BackgroundColor White "Press the button on the top of the Hue bridge."
    }
    elseif ( $hueUser.error.description ) {
        Write-Host -ForegroundColor Black -BackgroundColor White $hueUser[0].error.description
    }
   
    Read-Host -Prompt "Enter to continue"

    #Hue create account
    $body = @{ "devicetype" = "gateblu#$gatebluName" }
    $json_body = $body | ConvertTo-Json
    $hueUser = (Invoke-RestMethod -URI http://$ip/api -ContentType "application/json" -body $json_body -Method Post -ErrorAction SilentlyContinue)[0]

} until ( $hueUser.success )

$apiUsername = $hueUser.success.username

Write-Host "Open the Philis Hue Thing in Octoblu interface"
Write-Host "Select the Gateblu instance to connect to"
Write-Host "Enter: $ip as the ipAddress"
Write-Host "Enter: $apiUsername as the apiUsername"

# Return the full state
$hueState = Invoke-RestMethod -URI http://$ip/api/$apiUsername -ContentType "application/json" -Method Get -ErrorAction SilentlyContinue

"Configured Lights:"
$hueState.lights | Format-List

"Configured Groups:"
$hueState.groups

# Full configuration
# $hueState.config

How can my Checkpoints be consuming more storage than the root virtual disk?

I explain this in the forums every so often.

Folks Create a VM, then a few Checkpoints.  And before they know it they are in that horrific Paused-Critical state with their VMs.

All because they are running out of storage.

In the end, it comes down to many folks not really understanding how this happened in the first place.

It really goes back to the fact that Checkpoints use differencing disks.  And each differencing disk has the potential of consuming as much disk space as its parent.

First of all; the warnings:
Be sure to only delete checkpoints through the Hyper-V Manager.
Do not attempt to manually delete AVHD files on the local file system.

Also, dynamic disks do not matter.  Whether your VM began with a dynamic disk or a fixed disk makes no difference. 
A dynamic disk just gives the illusion of consuming less space as the full potential of the disk is not realized.
But all differencing disks are dynamic, regardless if the parent was fixed or dynamic.

The root concept here is:
Each Checkpoint disk has the potential of consuming the maximum amount of disk space that its parent did.

For example:  Say you make a VM with the default of a 127Gb dynamic virtual disk (you have the potential of consuming 127Gb of storage). 

You install an OS and only 14Gb of physical storage is used. 
You then take a Checkpoint.  Now, you have the root 14Gb, and the potential to consume another 127Gb of additional storage.
 
Time passes and this Checkpoint consumes 50Gb of storage.  14 + 50 = 64Gb consumed.
You now take another Checkpoint.  And all kinds of stuff happens in that VM OS. 
You install Visual Studio create a database application, who knows. 
And with all that the current state is now consuming 80Gb of Storage.

You have only increased the disk use by 30Gb. 
But, with the Checkpoint tree in place you have now consumed 14 + 50 + 80 = 144Gb. 
Beyond the 127Gb limit of the virtual disk. 

Because of the potential of each Checkpoint being able to consume 127Gb (of VM disk change) all by itself.

Side by side with this is folks that use Checkpoints or differencing disks with the false idea that they will save storage.  Over time, they save nothing and add complexity.
Unless you are doing test and are constantly tossing away VM disks and creating new ones, using differencing disks with the argument of reducing storage use is a very false assumption.