Install Angular9 or latest version using PowerShell

For fresh start, Uninstall Node.js and npm

Uninstall node.js and npm using Windows Installer (msi)

To uninstall node.js and npm, Open Windows “Control Panel” -> “Uninstall a program”, select Node.js and click on uninstall to uninstaill both node.js and npm

Cleanup directories

After the uninstall, look for the following folders and delete them if exists
* Nodejs installed directory
* npm and npm-cache directories from %appdata% directory
* npmrc directory from user home directory ( C:\Users\{User} )

Now to re-install

Go to Node.js page and install current version

https://nodejs.org/en/download/current/

Check node and npm version;

node -v

npm -v

Open PowerShell in admin mode;

If you want to uninstall angular;

npm uninstall -g @angular/cli

npm cache clean –force

npm cache verify

Install a specific version of angular;

npm install -g @angular/cli@9.0.0

If you see this error, don’t worry. Angular is installed.

ng –v

You might get PowerShell digitally signed error; run these commands;

To check current execution policy, Get-ExecutionPolicy. A convenient method is to change the Execution policy using this cmdlet.

PS C:\ Set-ExecutionPolicy unrestricted

Press Y to confirm. The policy change is updated in the registry and remains this way, at least until you change it again. The unrestricted means loading absolutely all configuration files and running all scripts.

If you don’t want to unrestrict policy but to bypass the policy for current process, run this command;

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

Now running ng -v will work.

If you want to Install latest version of angular;

npm install -g angular/cli

This is the Location where angular package are stored;

C:\Users\[UserName]\AppData\Roaming\npm\node_modules\@angular\cli\bin\ng

Resources

https://windowsreport.com/powershell-not-digitally-signed/

Connecting an Azure WebApp to a SQL Server VM inside a VNet

This article is about connecting an Azure WebApp to a SQL Server VM which is hosted inside an Azure Virtual Network. Typically a SQL Server VM would be hosted inside an Azure Virtual Network (VNet)  to isolate it from the internet by blocking all inbound and outbound internet traffic using a Network Security Group (NSG). In this scenario, connectivity  to the SQL Database is achieved by using the new VNet Integration feature found on the App Service component. Using this feature removes the requirement of an App Service Environment (ASE) for the WebApp thus reducing overall hosting costs.

Using VNet integration provides private outbound access from your App Service to resources in your VNet using the RFC1918 internal IP address allocation range (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) by default.

 Scenario

A web application is hosted in a WebApp which requires a connection to the SQL Database hosted inside a VNet.

The network topology of this scenario is shown below which uses the Regional VNet Integration option where both the WebApp and SQL VM are in the same region. Here we have a VNet called LAN-VNET which has two subnets, one for the VNet Integration used for delegating called interdelg-subnet and the other to host the SQL Server VM called vm-subnet.

Configuration Walkthrough

The following are the sequence of steps used to setup VNet Integration between a Web App and SQL Server with the assumption the SQL Server VM is already hosted inside a VNet.

1. Adding a VNet subnet

2. Provisioning  an AppSvc Plan

3. Provisioning  a WebApp

4. Setting up the VNet Integration

5. Validating SQL Server Security Settings

6. Testing connectivity to the SQL Server

7. Updating the Web App SQL Connection String

1. Adding a VNet Subnet

A dedicated subnet used by the VNet Integration feature is required to be added to the existing VNet hosting the SQL Server VM. The IP range should match the maximum number of AppSvc plan instances when fully scaled out as each instance would require a IP address. For this scenario I will be using a /27  prefix giving a total range of 32 address, however  5 address are used internally by Azure leaving 27 usable addresses for each plan instance.

2. Provisioning App Svc Plan

To use VNet Integration, you will need to provision an App Service plan using newer V2 scale units. Note if you are currently using V1 App Services, you will need to provision a new plan using V2 and migrate you apps to this new plan.

To confirm if you have selected the newer V2 App Services, the Premium plans should be shown as P1V2, P2V2 and P3V2. Here I will be using a Standard Plan S1 for this scenario highlighted below.

3. Provisioning Web App

Create a new Web App and ensure it is in the same region as the VNet. Also ensure you have selected the  App Service Plan you created above.

4. Enable VNet Integration

Under the Web App that was provisioned above, click on the Networking menu item to view the networking options and then click on “Click here to configure” under the VNet Integration heading.

Go to your app and click on networking. Click on vnet configuration;

Once the VNet Configuration form opens, click on the “Add VNet” to open the Network Feature Status blade. Select the VNet that hosts the your environment and then the Subnet that was created earlier for the VNet Integration. Then press OK to save the changes.

After you hit OK, the VNet Integration should be connected and ready for testing the connectivity. Remember the VNet Integration will route all outbound RFC1918 traffic from the WebApp into your VNet.

5. Validating SQL Server Security Settings

To reduce the surface area of attack, ensure the SQL Server can only accept connections within the VNet. This is done by setting the “SQL connectivity” option to Private (within Virtual Network) under the Security menu of the SQL Virtual Machine.

Also check the NSG attached to the SQL Server VM to ensure there is a rule to disable all outbound internet traffic. If there is a inbound rule called default-allow-sql as highlighted below, it is advisable to delete this rule if not required. This inbound rule default-allow-sql is normally created when the security on the SQL Server VM allows SQL connectivity via Public (Internet) connections.

6. Testing connectivity

To check connectivity between the Web App and the SQL server, we can use the  tcpping command from a console window. Go to the Web App that was created previously and click on the Console menu item to open a console window similar to below.

In the console window type the command tcpping <sql vm private ip address>:1401. All going well you should get a reply similar to that below where 10.0.2.4 was the private IP address of my SQL Server VM using the default port 1401.

For some strange, if tcpping doesn’t work, check Inbound Rule in your server windows firewall for SQL Server Database Engine (Tcp-in) port;

Sometimes portal changes doesn’t apply to database. why? don’t know.

Make sure that ICMP for IP is enabled on your server firewall otherwise ping will fail.

7. Updating the Web App SQL Connection String

Once the connectivity has been verified, the next step is to update the connection string on the Web App to use the private IP address of the SQL Server VM. Typically the connection string should look something like this:- Server=10.0.2.4;Database=MyDb;User Id=myusername;Password=mypassword;MultipleActiveResultSets=true

After the connection string has been updated to use the private IP address, you should be able to test your application.

VNet Integration provides an easy and cost effective solution to access databases hosted within a VNet without resorting to a dedicated  ASE. Also using rules on the NSG applied to the SQL Server VM provides the capability to block all internet traffic and allow only RFC1918 internal addresses to have access.

Resource

https://docs.microsoft.com/en-us/azure/app-service/web-sites-integrate-with-vnet

Azure stencils for Visio

Download from here;

https://github.com/sandroasp/Microsoft-Integration-and-Azure-Stencils-Pack-for-Visio

After download, do this;

Copy to the folder “%USERPROFILE%\Documents\My Shapes” (“C:\Users\you_user\Documents\My Shapes”; that is the default folder for the Visio custom shapes)

To access the shapes in Visio, select the Shapes Windows:

“More Shapes -> My Shapes -> Microsoft Integration Stencils v#.#”

“More Shapes -> My Shapes -> MIS Apps and Systems Logo Stencils v#.#”

“More Shapes -> My Shapes -> MIS IoT Devices Stencils v#.#”

“More Shapes -> My Shapes -> MIS Support Stencils v#.#”

Installing PowerShell and Az moduel for Azure

Microsoft has switched from AzureRM modeule to Az module. Here is GitHub link to download and install;

https://github.com/PowerShell/PowerShell/releases/tag/v7.1.3

The easiest method is to download. Navigate to the release page;

As of this writing v7.2.0 is available. Scroll down the page and you will see this msi package under Assets;

Download and install. To test open PowerShell in admin mode and type this;

$PSVersionTable.PsVersion

Your PowerShell installation is done. It’s time to install Az-Moduel to interact with Azure.

Install-Module -Name Az -AllowClobber -Force

The -Force flag will install a second version of this module if one already exist.

You might be prompted for NuGet provider pre-requisite at installation startup;

Run this command to install pre-requisite;

Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force

Re-run Az installation command;

Install-Module -Name Az -AllowClobber -Force

This might take a minute or two depending on your connection speed. Once done, i can run this command to see how many Az module version i have installed;

Get-InstalledModule -Name Az -AllVersions | Select-Object -Property Name, Version

Since i have only a single version installed, so that’s what i see. if i had multiple versions installed, i would have seen many lines. By default, PowerShell uses the most recent version.

This concludes installation of Az module into PowerShell.

Time to do some good stuff. Run this command to connect to Azure;

Connect-AzAccount

This will open up browser and ask about your credentials. After verification it will show that your session is authenticated. Navigate back to PowerShell an you can see authentiation message.

If you have multiple Active Azure subscriptions, First one will be selected by default.

Run an azure resource command to confirm PowerShell is working;

Get-AzVM, Get-AzWebApp

Switching to another subscriptions

Run this command to see all of your subscriptions;

Get-AzSubscription

You will see a list of assigned subscriptions. To switch to another subscription, store your subscription in a context variable and switch the context.

$context = Get-AzSubscription -SubscriptionId <Subscription ID from list of subscriptions>

Set AzContext $context

Hope this will help.

DistributedCom error when running SSIS package on windows box

When I run integration services package from inside of the windows box, they work. When I try to run them from outside of the box using my laptop, they fail. SQL Agent job works from either side.

Upon further investigation, I noticed these events in windows system event log;

It seems that DistributedCOM component has permission issue; Add user’s to this window group;

Now we need to perform some DCOM component configuration to grant access to the Integration services service.

Run Dcomcnfg.exe. Dcomcnfg.exe provides a user interface for modifying settings in the registry.

On the location tab, make sure “Run application on this computer” is checked.

On the security tab, click Edit in the Launch and Activation Permission area. Add users and assign appropriate permissions, and then click ok.

Repeat above steps for Access permissions.

Restart database server.