[MUSIC].
>> In the next 10 minutes,
we will look at the process to register
Azure Stack as well as market for multi-tenancy,
onboard a new customer,
tag it to the appropriate CSP tenants, and then offboard a tenant.
The process to deploy Azure Stack involves multiple steps.
During the deployment and configuration,
there are a number of important milestones.
The first one being selecting the identity provider together with
the other prerequisites which are asked by the hardware vendor.
The identity provider is the actual AD
which will be used to authenticate in the admin portal.
This is very important and cannot be
changed without actually redeploying the entire stack.
Once all the deployment prerequisites are identified,
the hardware partner will continue with the deployment itself.
This is completely driven by the hardware partner
themselves and at the end of it,
you will have a working,
functioning Azure Stack deployment
which will then require registration.
The registration enables
marketplace syndication and usage reporting.
For registering your Azure Stack,
you will need an Azure subscription which in the case of a CSP,
it will be the shared services
or Internal Usage Rights subscription.
The shared services subscriptions are
the preferred choice for registration,
but there are some exceptions.
One thing to note is that the shared services subscriptions
are associated with a shared tenant or a shared services tenant.
This tenant is different than the AAD
you've used to actually register Azure Stack.
The two do not have
a common AD and they're not the same directory.
So this is perfectly okay and there is no issue whatsoever to
using a different tenant from
the one you've used for your identity provider.
Once the registration is complete,
you will now be able to onboard new tenants on Azure Stack itself.
Here you can see new deployment of Azure Stack
where the registration piece was not done yet.
So if we go into the marketplace management,
you'll see that we will
be prompted with a message saying we need to register first.
The registration is triggered using an owner of that subscription.
So in my case here,
I am using the admin@AzStackReseller1
which is an owner of that subscription.
It only has one subscription in
that directory so I don't need to select it.
I'll just go ahead and first
register the resource provider and then
trigger the actual registration piece using the Azure Stack tools.
Once the required modules are imported,
the registration is kicked off and the process will go on and
register your Azure Stack deployment
to the respective Azure subscription.
Once the registration is complete,
you will have access to the marketplace syndication.
and usage reports will be sent to
the Azure commerce servers or in the case of the CSP,
the partner center itself will display that usage.
If you would also stop here and not enable multi-tenancy,
the entire usage will be reported against
the initial subscription you've used for the registration.
So in the CSP case,
if you've used the shared services,
the entire usage reports
will fall under that shared services subscription.
Once the registration is complete,
you can go back to the marketplace management, refresh the portal,
and you will see the add from Azure option,
which will give you access to
all the images available on the Azure side.
So if you click here Windows Server 2016,
you'll be able to download the image and kick start the process to
make it available on the Azure Stack side.
To enable multi-tenancy on the Azure Stack side,
you actually need to go through a two-step process.
The first one will configure
the Azure Stack Directory and
the second one will configure the Guest Directory.
In my case, AzureStackReseller1 is my Azure Stack directory.
This is the one I'm using to actually log in Azure Stack on
the management side and it's the one I've
used as an identity provider for Azure Stack.
My Guest Directory in this case will be AzureStackTest1.
This corresponds to a CSP tenant.
So on the partner center side,
I've created a tenant called AzureStackTest1.
This is the actual tenant I'm using
to onboard on the Azure Stack side.
So the first step is to configure the Azure Stack Directory.
This is a simple registered-easy guest directory tenant command.
Once this is complete,
you will need to run the second part which is
the configured guest directory piece.
The second part you will run with
the admin from the tenant you plan to onboard side.
So in this case,
it will be an admin@AzStackTest1.
This will be used to configure the actual guest directory.
So we can run this command now and we
will use the credentials of that admin.
It needs to be a global admin in the respective AAD.
That will create all the objects and so on to
enable users from the directory to log in Azure Stack.
In this case here,
you will see a small error
which appears because we are logged in now
with an admin from the tenant we plan to on board.
So the error, it's a fairly common error.
We only need to run simple command,
which is Add-AzureRMEnvironment.
So we need to specify the actual environment we are going to use.
Once this is done,
we can rerun the script,
use the same Global admin we've used from
the tenant side and give it the proper password,
and it will go through all the steps required.
There's a number of steps it needs to do and there are
some objects it needs to create in the guest directory.
Once these are all complete,
these users will be able to login
Azure Stack and create new subscriptions.
Each of the newly created subscriptions
will enable the tenants to create resources,
and virtual machines, and so on,
which will in turn generate usage.
This usage is being piped at this point to
the initial subscription we've
used to actually register Azure Stack.
So because this is a CSP scenario and a multi-tenancy scenario,
right now, all the usage is being sent to one subscription.
So the next step will be to tag each of
these subscriptions and match them to the appropriate CSP tenant.
Once the onboarding is complete,
we can open a new browser in private and connect the user portal.
Now, we will be using
an admin or any user from the tenant we've just onboarded.
That tenant will have access to our Azure Stack,
and we'll be able to create a new subscription.
Now, this is a newly created Azure Stack.
So we don't have any offers created yet,
so that this tenant will not be able to create
anything because it's not seeing any offers available.
This will be part of another video.
Once those offers are created on the admin side,
they'll be usable by the tenants onboarded.
The product group has published a white paper,
which describes all the steps
required to enable multi-tenancy DAG,
the appropriate tenants, and match
these to their respective CSP tenants.
The white paper itself can be found on the EAI portal,
and we will link this to the webcast as well.
It goes through all the details required
including descriptions of the billing,
and then the reasons why you should register your stack,
and then details on the initial registration.
These are the things we've already talked in our video,
but you will find more information here about it.
Then we're coming to
the step where we're actually registering the tenant.
So in the case where we have
already onboarded on your tenant on Azure Stack,
we have the CSP tenant configured.
Now, we need to actually
get our registration approved to use multi-tenancy.
This is the step described here,
where we need to prepare an e-mail which looks like this,
and it includes the Resource ID,
and the Resource Group ID,
as well as the snapshot of the registration we've done.
To pull this information,
we will need to go on the Azure site.
Here, you see my AzStackReseller1 tenant
and this is my only Azure subscription,
where I have this registration of my Azure Stack.
So all these informations will need to be sorted and
added inside an e-mail sent out to this alias,
and then this will trigger
an multi-tenancy to be enabled or tagging to be enabled for you.
Once this is complete,
you will be able to actually run this command and map
the respective Azure Stack subscriptions or tenants
to the CSP tenants and their respective subscriptions.
When this is all complete,
what happens is that during the reconciliation of the usage,
each CSP tenant will receive their respective usage.
So you'll be able to see the usage
of each of the tenants inside partner center,
and then that will flow to your billing solution and so on.
Here, we are connected to the default provider subscription.
Running this partial command,
we will get all the onboarded tenants.
So as you can see, we have two tenants onboarded,
a Test1 and Test2,
and we will go ahead and remove offboard test two.
Now, to do this,
we will need to start the other way
around from the onboarding part.
So we will start with actually configuring
the tenant directory first.
This will remove
the installed Azure Stack identity applications and
their permissions within the colors Azure Active Directory tenant.
So running this, we will use the global admin from that tenants,
so in my case test two,
and this will remove that identity application.
Once this is complete,
we will run a second command on the Azure Stack site.
So this will be configuring
the permissions on the Azure Stack itself, right?
It will remove all the permissions necessary,
and it will essentially offboard the tenant.
To accomplish this, we will need an owner
of the Azure Stack default provider subscription.
Once this is complete,
that tenant is essentially offboarded.
So if a user would go ahead and try to login,
they would get an error page saying that it doesn't work.
So if we run the same command
to get the tenants which are onboarded,
you will see that now we have only AzStackTest1.
So if we were to open a new browser and tried to
use the tenant which we've offboarded,
so AzStackTest2, they will still have the sign-in.
But once you try to login,
you would actually get an error message which says
that the account is not
authorized to access the portal because we offboarded it, right?
If we instead would use the AzStack,
let me pull the login.
So if we go to portal,
we're using the AzStackTest1, right?
So AzStacktest1.
This will still work.
The users are still able to login and to use the portal.
[MUSIC]