Starting VS Code Insider from Command Line

If you’re like me, you love living on the digital edge, and using the newest bits all over.

When you go from Visual Studio Code, and step into Visual Studio Code – Insiders however, you will quite fast experience that you no longer can simply type code .\ from the command line to start developing. This is because Microsoft is nice enough to ensure that you can co-run these two together, and the command would actually be code-insiders .\

To solve this, you simply have to copy two files and rename them to code.

Note! This will break the coexisted experience between VS Code and VS Code – Insiders.

Let’s step trough them

    1. Browse to the path where you have installed Visual Studio Code – Insider. Default path is C:\Program Files\Microsoft VS Code Insiders\bin.
    2. Copy code-insiders and code-insiders.cmd and paste them back in the same folder.
    3. Rename both copied files to simply code and code.cmd

That’s it. You can now start Visual Studio Code – Insiders from the command line just as you’re used to.

Creating a Self-Signed Code Signing Certificate for AD FS Signing and Decrypting

Some times we don’t want to use automatic rollover for the certificates in AD FS, simply because we want even more granular control on what’s going on. To solve this we can either buy an public signed certificate from an CA we trust, or we can create a self-signed certificate our self using makecert.exe. Note that I would recommend a publically signed certificate for production use, but if you’re not as paranoid as me, self-signed works just as fine. A tool we can use for certificate creation in the Microsoft world, is makecert.exe. makecert.exe is a part of the Windows SDK. It’s also included when you install Visual Studio. The path for Makecert should be something like this on our computer

  • Version 6.3.9600.17298 – C:\Program Files (x86)\Windows Kits\8.1\Bin\x64\
  • Version 6.3.9600.17298 – C:\Program Files (x86)\Windows Kits\8.1\Bin\x86\
  • Version 6.2.9200.20789 – C:\Program Files (x86)\Windows Kits\8.0\Bin\x64\
  • Version 6.2.9200.20789 – C:\Program Files (x86)\Windows Kits\8.0\Bin\x86\
  • Version 6.1.7600.16385 – C:\Program Files (x86)\Microsoft SDKs\Windows\7.1A\Bin\x64\
  • Version 6.1.7600.16385 – C:\Program Files (x86)\Microsoft SDKs\Windows\7.1A\Bin\

The syntax for makecert is as follow

makecert [options] outputCertificateFile

To make a certificate that can be used with AD FS signing, our command should be like this (All in one line)

makecert -r -pe -n “CN=MySigningCert” -b 12/28/2014 -e 01/01/2020 -eku -ss my -sr localMachine -sky exchange -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12 “MySigningCert.cer” -len 2048

This should be successful. We can now export the key form our computer, and use it in the AD FS service.

The options we use in the example above

We used the following options in our script. Most of this table is copied from the official documentation.

-r Creates a self-signed certificate.
-pe Marks the generated private key as exportable. This allows the private key to be included in the certificate.
-n Specifies the subject’s certificate name. This name must conform to the X.500 standard. The simplest method is to specify the name in double quotes, preceded by CN=; for example, -n “CN=myName”.
-b Specifies the start of the validity period. Defaults to the current date.
-e Specifies the end of the validity period. Defaults to 12/31/2039 11:59:59 GMT.
-eku Inserts a list of comma-separated, enhanced key usage object identifiers (OIDs) into the certificate. The following MSDN document contains a list of supported OIDs
-ss Specifies the subject’s certificate store name that stores the output certificate.
-sr Specifies the subject’s certificate store location. location can be either currentuser (the default) or localmachine.
-sky Specifies the subject’s key type, which must be one of the following: signature (which indicates that the key is used for a digital signature), exchange (which indicates that the key is used for key encryption and key exchange), or an integer that represents a provider type. By default, you can pass 1 for an exchange key or 2 for a signature key.
-sp Specifies the subject’s CryptoAPI provider name, which must be defined in the registry subkeys of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults\Provider. If both -sp and -sy are present, the type of the CryptoAPI provider must correspond to the Type value of the provider’s subkey.
-sy Specifies the subject’s CryptoAPI provider type, which must be defined in the registry subkeys of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults\Provider Types. If both -sy and -sp are present, the name of the CryptoAPI provider must correspond to the Name value of the provider type subkey.
-len Specifies the generated key length, in bits.

List of some possible Providers and Provider Types

The following list is based on the available Providers at my dev machine.

Provider Name Provider Type
Microsoft Base Cryptographic Provider v1.0 1
Microsoft Enhanced Cryptographic Provider v1.0 1
Microsoft Base Smart Card Crypto Provider 1
Microsoft Strong Cryptographic Provider 1
Microsoft Base DSS Cryptographic Provider 3
Microsoft RSA SChannel Cryptographic Provider 12
Microsoft Base DSS and Diffie-Hellman Cryptographic Provider 13
Microsoft Enhanced DSS and Diffie-Hellman Cryptographic Provider 13
Microsoft DH SChannel Cryptographic Provider 18
Microsoft Enhanced RSA and AES Cryptographic Provider 24


If you ever forget the password for an PFX file

Had a case yesterday where we needed the password for a Certificate PFX file.

Luckily we found this tool, and after a short time using brute force we got the password:

If you have a netbook or a small laptop, why not spin this up in Azure using a Linux machine?

Anyhow, it works, and the service is back on line 🙂

Access apps enter GA

As I’m in Norway, and day has become night when Microsoft wakes up, I need to repeat myself once more. Yesterday, the Office 365 team announced that Access apps enter GA.

It might sound like creating something I Access is to take a step back in time, but when you first try the power in combining Access apps with SharePoint I can almost guarantee you that you will regret that thought.

Give it a try, and have an open mind for old heroes…

Performance Analysis of Log (PAL) Tool

We have all been there. You install a system, and everything works just perfect. Then, after a few weeks or maybe months, things begin to happen, and your task list fills up with users complaining about poor performance.

Therefore, you dive in and monitors a bunch of counters you found using your favorite search engine on the internet, but everything looks just fine. Well, I know, it is a real pain. This is where PAL could be your savior.

Over at CodePlex, there is a tool with the describing mane Performance Analysis of Log Tool, or just short PAL.

What PAL can do for you is to create a Perfmon template with just the interesting counters. After you have created a new Data Collection Set using this template and collected some data, PAL then analyze the output for you. What you then need to do is to read though a HTML document, looking for any red or yellow text.

In the steps below, I crated a template for Microsoft Active Directory, and let it run on a DC in my LAB network. While it run, I created some bad powershell scripts that did some searching in AD, and some IO intensive operations to the disk. We should get some red flags…

After you have installed PAL, open it and navigate to the Threshold File tab. Then simply select a predefined template in the Threshold file title drop down box, and click Export to Perfmon template file. To see, or edit, the counters used in this template, simply click Edit before exporting the file.


Save the exported XML file to a known location, and copy it to your Active Directory Server.

Safely there, open Performance Monitor, and expand Data Collection Sets and click User Defined. Right click User Defined, and select New, Data Collection Set. To learn more about Data Collection Sets take a look at this link


In the wizard that pops up, give the DCS a good name like PAL_ActiveDirectory, and make sure that Create from a template (Recommended) is selected. Then click Next.


Now we want to select our exported template. Click Browse… when asked to select template, and find to XML file you imported.


You should then end up with something like this


Then just click Finish, unless you want to run this under a specific account, or want the data saved elsewhere. Now start the collector and let it run for a few hours. You could also schedule this, as you normally would do when working with Data Collection Sets.

OK, so our DCS have been running for a few hours, and it is time to do something with the data.

Sign in to the domain controller, and copy your perfmon log from C:\PerfLogs back to your computer where you have PAL installed. The next job could take some time. Depending on the amount of data you have collected, and how badass your computer is, this could take hours. On my old HP 6465b laptop, it took about 3.5 hours to process about 550MB of Exchange 2010 log files using one tread.

First, go to the Threshold File tab, and choose the same template and settings you used earlier. Then open the Questions tab, and select correct Operating system, and the amount of Physical Memory (or virtual) installed on the DC. As the last step before beginning the analysis, open the File Output and specify an Output Directory.

If you open the Queue tab you should see something like this. The window is showing how you could execute the job without using the PAL Wizard.


Then go to Execute, and click Finish. Now, wait while PAL does its magic.



After some time, the analysis is done.


And you are left off with a great report to study. Have fun doing it. If you are a bit geeky like me, it could actually be some interesting reading.