0 Comments

Yet, Internet connection sharing is an easy-to-use feature on my Xiaomi Redme Note 5 phone that has wasted me whole evening to get it right. Funny thing, really, since as a user I was supposed to enter Settings, navigate to Mobile Hotspot, define password and swipe to enable it. Also from that point of view, that’s all you can do, due to lack of any other configuration options. But as it turned out, there is a subtle “bug”, that causes it not to work on any Xiaomi phone (with MIUI and without).

Short story long… Of course data connection on the phone itself was always working fine. I could browse the net, connect via VPN to work network, watch YT, listen music from Spotify etc. Several times I needed to share this LTE connection with the Windows 10 laptop to perform some immediate tasks and it always failed. No matter what hour I tried, or the part of the city I was sitting. Then I mostly gave up and turned back for few moments to my BlackBerry Passport phone, where it was always working smoothly ;)

Finally I realized it’s time to find a solution to this issue. And here it is, few hours later.

I browsed the Internet and found all those misleading guides, that lead to nothing, so simply skip them:

  1. First I thought it was due to problem with the way my APN (settings for data-connection) was defined:
    • Switched to IPv6 only
    • Reset everything to default
    • Confirmed with my mobile operator, whether default is right
    • Switched APN type to ‘default’
    • Switched MVNO type to ‘GID’
    • Switched to IPv4/IPv6
  2. Set hotspot frequency to 5 GHz
  3. Reset device, place SIM card in secondary slot
  4. That all was wrong, still I could only to connect the PC to the hotspot, but no packets were actually transmitted over the LTE. Then I thought – maybe it’s the problem with Windows itself. So I tried:
    • Forced IPv6
    • Reset network settings to default
    • Hardcoded Google DNS – 8.8.8.8
    • ipconfig /renew
    • ipconfig /flushdns
    • ssh to any external server

Continuously nothing working correct, even when all the guides I have seen were claiming, it should be fine long ago. I have even found info about Samsung and Huawei devices, where IP ranges or default DNS can be defined directly on mobile.

Then boom! What if this is Xiaomi-only related “bug”. And that’s true. It flies around since several years and xda-developers.com has even a fix, that looks like:

  1. install Android SDK
  2. enable developer mode on the device
  3. enable USB debugging and especially USB debugging extra security settings (without it further commands will throw security exception; also it might require registering at Xiaomi portal as developer)
  4. connect the device via USB
  5. in command prompt type adb shell to issue further commands on the device directly
  6. check value of tether_dun_required, that in my case was `null` as described in the original fix, with command: settings get global tether_dun_required
  7. if the value is different than ‘0’, hotspot will not work
  8. to set it type: settings put global tether_dun_required 0
  9. exit shell and reboot the device


And now it works finally!

0 Comments

Some time ago I have shown how to configure automatic build of SSIS projects (SQL Server Integration Services). Unfortunately they require full version of Visual Studio installed on a build machine as it’s an overwhelming plugin (not only a toolset), what potentially could hit me back.

And well, of course it failed and hit me after 30 days! Turned out Visual Studio 2017 Community Edition expired and was refusing to cooperate more, producing this nice error log:


[12:08:30][Step 2/3] Starting: C:\TeamCity\buildAgent\temp\agentTmp\custom_script7138984668293949066.cmd
[12:08:30][Step 2/3] in directory: C:\TeamCity\buildAgent\work\2906b7d01f979ef5
[12:08:51][Step 2/3] 
[12:08:51][Step 2/3] Microsoft Visual Studio 2017 Version 15.0.27428.2027.
[12:08:51][Step 2/3] Copyright (C) Microsoft Corp. All rights reserved.
[12:08:51][Step 2/3] 
[12:08:51][Step 2/3] The license for Visual Studio has expired.
[12:08:51][Step 2/3] 
[12:08:52][Step 2/3] The evaluation period for this product has ended.
[12:08:52][Step 2/3] Process exited with code 1


Nothing simpler, I run Visual Studio and entered my credentials, that created a proper license etc. All the warnings on UI were gone. All was supposed to go back to normal, but somehow the same log appeared again.

Till now, it was actually my naïve thinking, as Visual Studio was launched in a context of a totally different user than the one used when I double-clicked the shortcut icon. Build system operated as the local system account, since it was the “TeamCity Build Agent” service that was configured to start it.

I tried to use RunAs plugin for TeamCity. I installed it, created dedicated BuildTool user, even configured in “Build Features” section of the build configuration. Of course I run Visual Studio as this user and entered obtained again the license. But automatic build process was still failing with this log:

[13:12:58][Step 1/3] MSBuild output
[13:12:58][MSBuild output] Access is denied.
[13:12:58][MSBuild output] The current directory is invalid.

I should have probably focused more on this message and grant read/write access for new user to the buildAgent folder (as this is the place, where the sources gets populated and processed) and that would be probably the final solution (even mentioned here). But since I am hot-tempered, I moved to another try.

Next, I reconfigured the whole TeamCity Build Agent service to start as BuildTool user. I added proper login permissions (to allow it to boot the machine, login as a service etc., more here), along with access to mentioned above folder.

TeamCity Build Agent service log-on properties

Since now on, I had no issue anymore and all builds successfully again.


Congrats!

0 Comments

Recently, I have shown, how to enable Application Insights within own WCF server application (look here). It might similarly work in other kinds of apps, so we won’t bother with further demystification of this procedure. But as you might suspect (or already stepped on), you will quickly require more metadata transmitted than it is done by default.

My scenario is pretty simple. The WCF server is installed multiple times, in multiple physical locations across the whole country. And they all just sit there, working since most of the bugs aren’t so critical. It can’t be even updated everywhere at the same time. So how to actually distinguish between different instances and app versions in case of a crash or other serious misbehaviors?

And the answer is – ITelemetryInitializer.

This kind of objects are responsible for performing initialization of the telemetry data gathered and then sent back to the Azure’s AppInsights service.


Here is the recipe, how to define and enable one in own project:

1) First create a class that implements ITelemetryInitializer interface.

2) Within Initialize() method, set additional context properties. To match my scenario, let it be two fields:

  • ClientInstance” – to let know, which server it’s running on (yes, it should be read from external configuration file, but should be clear enough for now, as I hard-code it)
  • BuildInfo” – to inform about application version running there, which I read directly from the assembly name

Of course the way it was obtained should be updated to match the logic in your app.

public sealed class ClientInstanceTelemetryInitializer : ITelemetryInitializer
{
    private const string ClientInstanceParam = "ClientInstance";
    private const string BuildInfoParam = "BuildInfo";

    private readonly string _instance;
    private readonly string _version;

    public ClientInstanceTelemetryInitializer()
    {
        _instance = "beaa9ac0-3267-41e4-9c14-2167271aca4d"; // should be different for each running instance
        _version = new AssemblyName(Assembly.GetExecutingAssembly().FullName).Version;
    }

    /// <inheritdoc />
    void ITelemetryInitializer.Initialize(ITelemetry telemetry)
    {
        telemetry.Context.Properties[ClientInstanceParam] = _instance;
        telemetry.Context.Properties[BuildInfoParam] = _version;
    }
}

3) Finally, register the initializer via ApplicationInsights.config file (this file was added automatically to the project, when AppInsights NuGet packages were installed inside the previous guide). Simply add the type at the end of TelemetryInitializers section. It will be instantiated automatically at application startup.

Telemetry Initializers

And that was all again.


Verification:

Now, when navigating to the crash logs on Azure, open a request details, click ‘Show all’ properties and the view should look similar to this one:

Azure Telemetry Info

“Custom Data” section contains info about ClientIntance and BuildInfo as expected.


Thanks!

2 Comments

Here I would like to present a small recipe, that will let you enable monitoring of WCF server-side calls with Microsoft’s ApplicationInsights service. It might help you in analytics of:

  • what services are used mosts
  • what hours users are active
  • what are the response times
  • what is called far too often and needs optimization
  • and probably most important thing - what crashed, why, when with the callstack!

It’s pretty straightforward and I split it into two parts.
First part - tasks are required to be done on the Azure side. For the foremost – you will need an Azure Account and an active subscription. I am assuming you already got one. Details are out of the subject for this tutorial. Even though Azure is a paid service, an ApplicationInsights till first million of actions is free as I remember correctly.
Second part – how to update the server-side of an application to utilize the Application Insights service. It focuses on proper packages installation via NuGet and the configuration.


Let’s go then. Do it on Azure:

  1. Login into Azure Portal.
  2. Click on “Create a resource” and input “Application Insights” in a search field. Then click “Create” button.

    Azure Create AppInsights resource


  3. Select an “ASP.NET web application” and complete the process.
  4. After few seconds, new service will be created, navigate to it.
  5. What is really required to store/remember is called “Instrumentation key”. Obtain it from the “Properties” section or via “Essentials” part of the “Overview” section as shown below.

    Azure AppInsights Overview


  6. We are done here.


Now, it’s time to update the ASP.NET WCF application, to post metrics and call to Azure appropriately.

  1. Open your solution in Visual Studio 2015 Community (or newer).
  2. Navigate to “Tools –> NuGet Package Manager –> Package Manager Settings –> Package Source” as on picture below.
  3. Add new source for AppInsights SDK (open-sourced and hosted on GitHub).

    NuGet Sources

    Name it anyhow you like, and use “https://www.myget.org/F/applicationinsights-sdk-labs” as source URL.

  4. Install the package: “Microsoft.ApplicationInsights.Wcf” (Include prerelease should be checked). It should also download all other packages it depends on.

    AppInsights Packages

  5. Now, inside the Globa.asax file, update the “Application_Start” method. Enable the monitoring of the application by placing the “Instrumentation Key”. The value we got earlied from Azure Portal, when the cloud service itself was created.

    TelemetryConfiguration.Active.InstrumentationKey = "my-instrumentation-key";

    AppInsights Instrumentation Key


  6. All the other necessary configutaion could be tweaked via code or ApplicationInsights.configfile, that was added to the project during packages installation. At this time, we don’t need to modify it anyhow.
  7. So we are done. Now the new version of the application is ready to be deployed. Once this is finished, statistics will be uploaded and visible through poral almost in real time.

    If you can visit the portal again after some time, instead of being empty, it should display content as follows:

    Azure AppInsights working

That was it!

0 Comments

After recent upgrade to Windows 10 Fall Creators Update my wake-on-lan feature of the desktop PC stopped to work. It was not very surprising, as most of the settings during such a big OS update usually goes to defaults.

Here are two simple steps to restore it. Only two - as I already had it enabled in my UEFI BIOS on the motherboard and also installed drivers for my build-in Intel network card 82579V. However I am not sure, if this driver update is required at all and the default Microsoft’s one will suffice. Anyway:


  1. Launch Device Manager and navigate to Network Adapters. Then on Power Management tab of the network card enable all “wake up” options. Also on Advanced tab enable Magic Packet.

    Enabling Magic Packet (Win PL)


  2. Navigate to Control Panel, then go into Power Options and on the left side click Choose what the power buttons do. After that go into Change settings that are currently unavailable. Finally uncheck (disable) fast-startup mode to let the PC respect the network device power settings (set in previous step).

    Disabling fast-startup (Win PL)


That’s all what is needed!