Netflix and opendns are not friends – netflix support sucks.

For some reason I had not opted to let the Netflix app on my Android TV and one day with an Android update it decided it was going to be using 4.0.4 build 1716 instead.

Then Netflix would not be able to load any video with somewhat getting stuck at 25% with the lovely error of tvq-pm-100 3.1-52.

Life after work ended. The evening entertainment was ruined for ever and I was not the same again. The downwards spirals was inevitable.

I chatted with Netflix, spends hours on the phone going through the meaningless scripted troubleshoot – had I restart my TV box? Log off and back on? clear the cache? reset the appliance? nothing I was on the verge of video deprivation.

The most intriguing aspect was the competent Netflix staff would say: well as it is not us, it must your network provider. Yet not able to say what getting stuck at 25% could mean. Where are the good old logs telling what is going on when you need them?

I then read on a forum that the Netflix Android TV app would rely on Google DNS to geo-triangulate you and spy on you.

In order to protect my household I had opted long ago for opendns to block the doubleclick and other webspam of the universe without issues in the previous versions of Netflix.

In the end, changing the DNS setting on that Android TV to use Google’s infamous DNS 8.8.8.8 and 8.8.4.4 to see Netflix videos loading at lightning speed and that very same Android TV box could again spy on me at will.

Thanks to Google’s sneakiness the end of the world was avoided.

Uninstall GP2010 and installation of GP2015

This document describes how to uninstall GP2010 and installation of GP2015.

Prerequisite: local admin rights to uninstall and install software on the machine

  1. Uninstall GP2010 following components
    1. GP2010, Mekorma MICR 2010, Integration Manager for Microsoft Dynamics GP 2010, Dexterity Shared Components 11.0 (64-bit)
    2. Remove the following folders
      1. C:\Program Files (x86)\Microsoft Dynamics\GP2010
      2. C:\Program Files (x86)\Common Files\microsoft shared\Dexterity
  2. Restart the computer
  3. Install GP2015 (includes dexterity 14) as usual.

Uninstall using WMIC

note that Mekorma not playing nice with wmic or msiexec – must uninstall manually.

wmic call Msiexec GUID
product where name=”Microsoft Dynamics GP 2010″ call uninstall /nointeractive {DC90A0A6-2D90-493E-8D13-D54AD123B9FD}
product where name=”Integration Manager for Microsoft Dynamics GP 2010″ call uninstall /nointeractive {FAFD8B80-E75F-4557-85F3-67B8D7A14E8F}
product where name=”Dexterity Shared Components 11.0 (64-bit)” call uninstall /nointeractive {F5459EB2-A662-4EB3-AD94-E771DC2F542A}
product where name=”Mekorma MICR 2010″ call uninstall /nointeractive {A45282DB-59DC-4A5D-9E1F-08A225D81A44}
To run on several nodes at the same time:
wmic:root\cli>/failfast:on /node:@”c:\temp\trainingwks.txt” product where name=”Microsoft Dynamics GP 2010″ call uninstall /nointeractive

Managing Certificates using Powershell

Because of my recent work with ADFS I was looking for a way to automate most of the certificate configuration by scripts. The usual run-books I write would usually include the use of the mmc and a bunch of screenshot to accompany them.

The answer is that powershell management for Certificates is there and here are some examples:

 

#Powershell exposes certs under cert:\
PS C:\> Get-PSDrive
Name Used (GB) Free (GB) Provider Root CurrentLocation
—- ——— ——— ——– —- —————
A FileSystem A:\
Alias Alias
C 14.37 45.29 FileSystem C:\
Cert Certificate \
D FileSystem D:\
Env Environment
Function Function
HKCU Registry HKEY_CURRENT_USER
HKLM Registry HKEY_LOCAL_MACHINE
Variable Variable
WSMan WSMan
PS C:\> cd cert:
PS Cert:\> dir localmachine
Name : TrustedPublisher
Name : ClientAuthIssuer
Name : Remote Desktop
Name : Root
Name : TrustedDevices
Name : CA
Name : REQUEST
Name : AuthRoot
Name : TrustedPeople
Name : My
Name : SmartCardRoot
Name : Trust
Name : Disallowed
Name : AdfsTrustedDevices

#Browsing through the stores is pretty intuitive
PS Cert:\> dir Cert:\LocalMachine\My
Directory: Microsoft.PowerShell.Security\Certificate::LocalMachine\My
Thumbprint Subject
———- ——-
E31234DEF282437D167A64FD812342B650C20B42 CN=XXXXa
8912343319B07131C8FD1234E250DC67CBE08D7A CN=XXXX
69AD2C21912340919D186503631234A6F0BE9F7F CN=*.xxx.ca,XXX..

#Exporting a cert is something a little less intuitive
PS Cert:\> $ExportCert = dir Cert:\LocalMachine\Root | where {$_.Thumbprint -eq “892F212349B07131C12347F8E250DC67CBE08D7
A”}
PS Cert:\> $ExportCryp = [System.Security.Cryptography.X509Certificates.X509ContentType]::pfx
PS Cert:\> $ExportKey = ‘pww$@’
PS Cert:\> $ExportPFX = $ExportCert.Export($ExportCryp, $ExportKey)
PS Cert:\> [system.IO.file]::WriteAllBytes(“D:\Temp\CertToExportPFXFile.PFX”, $ExportPFX)

#same mess for importing
# Define The Cert File To Import
$CertFileToImport = “D:\Temp\CertToImportPFXFile.PFX”
# Define The Password That Protects The Private Key
$PrivateKeyPassword = ‘Pa$$w0rd’
# Target The Cert That Needs To Be Imported
$CertToImport = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 $CertFileToImport,$PrivateKeyPassword
# Define The Scope And Certificate Store Within That Scope To Import The Certificate Into
# Available Cert Store Scopes are “LocalMachine” or “CurrentUser”
$CertStoreScope = “LocalMachine”
# For Available Cert Store Names See Figure 5 (Depends On Cert Store Scope)
$CertStoreName = “My”
$CertStore = New-Object System.Security.Cryptography.X509Certificates.X509Store $CertStoreName, $CertStoreScope
# Import The Targeted Certificate Into The Specified Cert Store Name Of The Specified Cert Store Scope
$CertStore.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite)
$CertStore.Add($CertToImport)
$CertStore.Close()

For import/export, I’d recommend using code from here: http://poshcode.org/?lang=&q=import%2Bcertificate

 

ADFS Proxy Trust certificate on WAP doesn’t auto renew

Once upon a time, the web application proxy for ADFS proxy started throwing error.

The Remote Access Management console could not do much complaining with an error code “the operation stopped due to an unknown general error” as always really helpful message.

Looking at the logs, the WAP was also complaining about establishing its trust with the ADFS server.

Fairly enough the ADFS proxy was also complaining about the trust saying that the proxy trust certificate had expired.

Back to the WAP and surely enough it was. However from the GUI I could not find any way to recreate the trust and had to use my DuckDuckGo powers.

So I found that the wizard had to be tricked for reinitialization prior to doing anything as in http://channel9.msdn.com/Events/MEC/2014/USX305

HKLM\Software\Microsoft\ADFS\ProxyConfigurationStatus

We need to set the ProxyConfigurationStatus REG_DWORD to a value of 1 (meaning “not configured”) instead of 2 (“configured”). Once that change is made, re-open the GUI. No reboot is required.

The Remote Access Manager should now allow you to re-run the configuration wizard.

I still don’t know why it would not renew, but given that the certification of the trust goes by every 2 weeks I will seen pretty soon.

Viewing queues in Exchange 2013 with powershell

Now that Microsoft have changed all the GUI management I struggled to locate the queue viewer. As it turns out it is NOT part of the Exchange admin center (https://localhost/ecp). This tool is part of the Exchange Toolbox, you will find with your management package for Exchange and the queue viewer works like before.

But obviously one would prefer powershell to do so, right!

Get-Queue and Get-QueueDigest will be you friends. You would need to know your DAG prior to that…

>Get-DatabaseAvailabilityGroup

Name             Member Servers                                      Operational Servers
----             --------------                                      -------------------
MY-DAG1         {MY-TOR-EX2, MY-TOR-EX1}

>Get-QueueDigest -Dag MY-dag1

GroupByValue                      MessageCount DeferredMess LockedMessag StaleMessage Details
ageCount     eCount       Count
------------                      ------------ ------------ ------------ ------------ -------
[10.77.77.12]                     227          0            0            0            {MY-TOR-EX2\66427, MY-TOR-EX...
Submission                        1            1            0            0            {MY-TOR-EX2\Submission}

graylog2 server not listening on ports 514 and 12201

I have managed to get the graylog2 server  v1.2.2 running with their virtual appliance.

Everything seems to work just fine, except that the graylog server instance
was not listening on the ports defined in graylog2.conf.

In netstat I see the graylog java process associated to the ports 12201 and
514, yet they are not in state LISTEN, and any log messages i send to my
machine on 12201 as gelf via udp are not picked up.

I read the getting started documentation for the setup from bottom up again but could not find anything.

Message inputs are the Graylog parts responsible for accepting log messages. They are launched from the web interface (or the REST API) in the System -> Inputs section and are launched and configured without the need to restart any part of the system.

I added those from the System>Input screen – boom – it started listening.

Oh well.

Looking for a good tutorial to setup graylog? have a look there.

SQL execution took too long on vCenter – SQL execution took too long: INSERT INTO VPX_EVENT_ARG WITH (ROWLOCK)

One day I woke with several warning alerts from foglight saying it got disconnected from a vCenter and reconnected almost right away but then flipping on and off all the time making foglight a bit spammy.

Looking at my vServer logs, I found out a repetitive peculiar message about queries taking too long while looking around the DB is undersized, and DB processes being responsive.

A few KB searches after, I read up that dbo.VPX_EVENT and dbo.VPX_EVENT_ARG tables are too large and must be truncated. (KB 2020507)

As per KB…

  1. Take a back-up of your current database. Do not skip this step.
  2. Use SQL Management Studio to connect to the vCenter Server database.
  3. Select New Query.
  4. Enter these queries in the new window and click Execute:

    Note: Execute each query separately and wait for the query to complete prior to running subsequent queries. Depending on the size of the tables, the process may take up to 15 minutes.

    • EXEC sp_msforeachtable “ALTER TABLE ? NOCHECK CONSTRAINT all”
    • USE name_of_the_vcdb
      TRUNCATE TABLE vpx_event_arg;
      DELETE FROM vpx_event;
    • Exec sp_msforeachtable @command1=”print ‘?'”, @command2=”ALTER TABLE ? WITH CHECK CHECK CONSTRAINT all”

Then all went back to normal after a restart of all services involved eventhough the KB title did not seem very related to my case.