Recently I came across an excellent blog post from Jethro Seghers that covered getting started with Office 365 PowerShell Automation. In the post Jethro walks through the process of setting up Visual Studio Code to work with Visual Studio Services. The process uses Git as the broker. The end result is that your scripts can be stored in a secure source repository.

In following the post I learned several lessons that I thought I’d share.

Installing GitHub Desktop

When you install GitHub Desktop it will want you to create a repository when it starts up. I recommend that you cancel the pop-up and select ‘Clone a repository’ from the main screen:


One thing that Visual Studio Services does not make easy is to get the URL for your repository. The URL is displayed when you first create a project but thereafter it is not that obvious to find… The easiest way is to go to the ‘Code’ section in Visual Studio Services and then select the relevant project from the ‘Files’ tab. You can then grab the URL from the browser address bar. (You’ll need the full URL inc. the https:// bit):


You can then use the URL to clone the repository:


If this is the first time that you are using Git then I recommend that you manually create a new folder for all of your work somewhere on your local drive (you can do this with File Explorer – no special tools required). DO NOT use OneDrive. If you do use OneDrive you will get file conflict errors when Git attempts to synchronise the local and source repositories.In the image above, all of my repositories are stored as sub-folders in Documents\GitHub.  The other aspect is that the cloning process will want to add the repository as a new folder which uses the repository name. You do not need to use the repository name. You can replace it with something shorter or meaningful. In the earlier Visual Studio Services image you can see that I used spaces when creating the project. This might look good in the browser but in reality those spaces are %20’s and they (a) make the folder path longer (b) look amateurish. Remember the cloning process will not work if a folder of the same name is already present.


You can validate that the set-up is complete by viewing the ‘History’ tab in GitHub Desktop and performing a ‘Fetch’:


You might notice that the ‘Fetch origin’ state is ‘Never fetched’. Tap on the Fetch origin button and after a brief period where the arrows spin the status should change to ‘Last fetched…’:


If this process fails then it is likely that you have authentication challenges.

Authentication error #1

When cloning or fetching the repository you might encounter an error where you need to sign into Visual Studio Services but for one reason or another your credentials are not accepted. I get that a lot as I have a personal Visual Studio account that shares its primary email address with my work account. As a result when I first set up a clone from my work machine I am redirected to use my work sign-in which promptly fails. The temporary work around is to use a Personal Access token. Once you have Visual Studio Code set up you can delete the Personal Access token as the module in Visual Studio Code does a better job with authentication.

Configuring Visual Studio Code

The process is straight forward – install the extensions and locate the local repository. When you identify the local repository the Visual Studio Team Services module will take over. You can use the ‘Open folder…’ option from the Start screen to browse to your local repository:



On selecting the folder you might be asked to sign into Visual Studio Services. If you’ve resorted to using a Personal Access token when setting up GitHub Desktop you should be able to sign in with your usual credentials rather than the token. Once signed in you can delete the personal token. Once authenticated your files will appear in the Explorer view:


The repository can be updated using the controls in the Sources view:


For example the vscode6 can be used to commit all changes to the source repository. All should be fine and you can start coding but you might encounter another authentication error when undertaking a pull, push or sync requests…

Authentication error #2

If when pushing, pulling or synchronizing your repository an error like this appears:


then as northerners would say you have “trouble at t’mill”. You can see more (unhelpful) detail by viewing the output by selecting ‘Open Git Log’ from the dialogue. The log is also visible from ellipses in the Sources view.

On inspection of the output you’ll probably spot a ‘error setting certificate verify locations’ error.


This error is associated with the SSL certificates that are bundled with Git. In particular the default ‘ca-bundle.crt’ certificates. Your initial response could be to triage by checking that the certificate is present at the location detailed by the ‘CAfile’ value. My advice is to not bother. It is highly likely that you will find that the path is wrong. It looks like when they updated Git they moved the default location but forgot to change the code. You’ll spend hours working out how to change it to the correct location only for more errors to occur e.g. ‘unable to get local issuer certificate’ . You’ll then spend more time scouring the web and following dead ideas. Do not bother.

The fastest fix is a clean installation of Git and Git Desktop.

  1. Uninstall Git
  2. Uninstall Git Desktop
  3. Restart your machine
  4. Reinstall Git with administrator rights (this is critical – see later)
  5. Reinstall Git Desktop

IMHO there are two critical items that combined can cause the error:

  1. Not installing Git using the ‘Run as administrator’ option
  2. Using the bundled certificates

As mentioned earlier the path to the bundled certificates is wrong. My recommendation is to use the certificates that are native to your machine as this avoids the path error. As you work through the Git setup screens pay particular attention to this one:


Pick the option to ‘Use the native Windows Secure Channel library’. Choosing the ‘Use the OpenSSL library’ option leads to path problems.

I’ve not tried it but it looks like you can rerun the Git setup using the installer without uninstalling first. If you’d rather dig deeper into solving the issue then I would start with SSL certificate problem: Unable to get local issuer certificate as once you fix the path you’ll probably get a new error or two… Usefully the uninstall process seemingly does not remove the connection details for your repositories and so you will not need to setup Git Desktop or Visual Studio Code again.






Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s