I carried out the deployment, which was pretty straightforward; I previously did a course on Azure, so it wasn't a problem for me. The solution requires very little maintenance, and I'm the sole admin.

It took around three weeks to realize the benefits from the time of deployment, as we had to migrate many of our older systems into Azure, and the integration involved a lot of other vendors. Our email was on a Linux server, and we had a different cloud provider, so the deployment required significant collaboration with multiple parties.

As a small organization, we didn't have a deployment strategy as such, but my approach was to communicate with the other solutions' vendors to gather the required information. Then, I migrated our Linux emailing system into Azure, after which I went for the data, so it was relatively straightforward.

The complexity of the initial setup depends on the deployment; cloud deployments are very straightforward, on-prem implementations are more complex due to the infrastructure, and hybrid deployments are always complex as there are many considerations and assessments to be made.

I was involved in the deployment and initial setup of Entra ID. It was not that difficult. It had medium difficulty. There is a Microsoft way of doing things. Microsoft certainly seems to have made things easier since then. Whenever I go back into the system, it looks like some of the usability improvements are there. 

I believe that we also contacted Azure support a number of times during our deployment, and they were quite helpful. They were helpful up to the point where I got contacted by a product manager for Azure Active Directory at the time, and they were able to walk us through some of the implementation challenges we had, so Microsoft, at least for us as we were adopting Azure and Azure Active Directory, had a lot of hands on help with getting set up. They are open to feedback as well. The implementation was about as difficult as I expected an implementation to be. It was not certainly a turnkey where it just works right out of the box, but I have had more difficulty implementing other Microsoft solutions.

The initial setup was pretty straightforward. The only complex thing is syncing your on-premise active directory into Azure AD. It's not overly complicated and they also give you very good support. It's not very difficult to set up.

The deployment took a couple of months in the end because we just wanted to do it at a pace that we were comfortable with. We did some initial tests on users. We synced them into Azure AD, made sure they could access what we thought they could access, and make sure they could still do the same job that they could do before. Then we synced across another set of test users, then a bigger test, and then eventually synced everybody else. We did it over the course of a month. Technically you could do it in less than a week, but we just wanted to be cautious and make sure that it worked as we expected.

In terms of the implementation strategy, we have two different Azure Active Directory setups. We have one in our development area, so we did the development area one first. We sure we worked out how to do the syncing correctly, making sure we can see all the attributes that were on the on-prem AD that were then turning up in Azure AD. And then once we did a development one and that worked as we expected, we then did the production one. We did it in a step-by-step approach. We did a small set of test users, a larger set of test users, and then the entire company. It was a phased approach.

The initial setup is straightforward. The deployment is simple. We possess Microsoft learning documents and public articles from Microsoft, along with community channels. If we aim to adhere to these instructions, the process is quite simple. Even a college graduate attempting to configure from the Entra web portal will find it easy to follow. The procedure is particularly straightforward for specific scenarios and the specific topics that Entra provides.

The initial setup is a relatively straightforward process because Microsoft gives you a lot of guidance on how to do it. They also have a tie-in with local Active Directory. So, if you are running a local Active Directory, you can easily integrate it with Azure AD. It is also one of the more powerful features of the solution because it is a SaaS solution, but you can still tie it in with your local identity store. That makes it quite powerful because many companies, before they go to the cloud, have a local identity store, e.g., Active Directory. Microsoft has a very easy process and some tooling to make it integrate with Azure AD, so your local identities, you can still be leading, but you can sync all those identities up to Azure AD quite easily and keep the identity storage up to date.

We are exclusively using Azure AD in BDO Global. In other BDO countries, most countries use local Active Directory in combination with Azure AD.

If you look at it from a BDO country perspective, you have everything up and running in about a week, if not quicker. In our global setup, that took a little bit longer, because we had to create a solution to synchronize multiple Azure ADs towards the global one. We did that via B2B, so our setup took a little bit longer as it also involved some custom development. If you only deploy Azure AD from a single company perspective, then it should be a relatively quick process.

Deployment is not that hard because it is a SaaS solution, so you don't have to deploy any infrastructure. All that is taken care of by the solution itself. It is a matter of configuring first-time use, then setting up a sync between your own identity store and Azure AD, which is quite an easy process. If you read through the documentation, then you can have that sync running in about a day.

The initial setup is straightforward. I completed most of the deployment myself with excellent support from the Microsoft support Team.

The initial setup for Entra ID is simple when opting for a full cloud deployment. We only need to onboard the users and enter the license. However, in a hybrid scenario, we require network connectivity from on-premises to the cloud. Additionally, a separate server is necessary to synchronize the users with the cloud. This process is time-consuming and intricate to manage.

I implemented Entra ID for three to four companies in Bangladesh. Additionally, for on-premises Active Directory deployments, I handled more than ten to fifteen projects. In the capacity of a vendor, I collaborated with a company that served as a local partner of Microsoft.

The deployment involves four or five teams, including IT, Networking, and Security.

In my previous role, the initial setup was quite simple. It was a simple case of install and follow some wizards, then you pretty much had it setup and synced to your Azure AD from the on-prem. Minimum effort was required.

The deployment was about three weeks, which was mainly the change process and getting it through our internal changes. It was quite quick. 

The product is easy to set up. You can set up an entire organization in one day. 

There is no maintenance needed. Microsoft takes care of everything. We just make sure that we check the synchronization. Even if there is a sync error, we will receive a notification. Usually, it fixes itself and syncs every hour.  

I was involved in the initial deployment. The setups are always complex. 

How long it takes to deploy depends on the client. We've done it in two days or one week. However, the main work is typically done across two days.

We tend to have two to three people involved in the implementation. 

It doesn't require any maintenance on our side. 

It is very simple. All you need to do is to create a subscription. When you create an Azure subscription, you will be creating an Azure account. If you are using Office 365, you already have an Azure Active Directory account.

If you go to Azure.com and use your credentials, you would be able to log in. So, you have a basic panel with services related to Active Directory, but if you need to deploy virtual machines or other paid services, you will need to purchase a subscription. I have my own environment, but I only use it for testing and for making records of customer issues to see what's happening or why the problem is coming.

It is a very easy-to-manage platform. There are many guides. As soon as you enter the portal, you will see all products and services. Every time you click on any specific service, you will find information about the service, its pricing, etc. You will get the required information needed on the platform. I also have experience with IBM's platform, but it was not as easy to handle as the Azure platform. 

Our initial setup was complex in some ways and easier in others. The complexity stemmed from the fact that we are a bank, and the security team chose the most complex deployment. Because the security people chose the most complex options, they are missing things. For example, self-service password reset is not working for us because it's one-direction communication.

In summary, our initial setup was complex because it was chosen as such. Although it is the most secure, we are missing some benefits that we would have if we had chosen a different setup.

The deployment itself was not very long. However, the planning stage was lengthy because of the in-depth discussions with the security team. Overall, the deployment took perhaps two weeks or less.

Our deployment strategy was a rather high-level approach and considered that our primary identity provider is on-premises AD, which means that we were able to take some of the details from there. We did not have to consider everything from scratch. For example, our password hash is one-way, so there are no writebacks. We defined it this way because it's quite secure. Similarly, we needed integration with third parties, such as other cloud providers. This meant that we were not afraid if something is breached because there would be no impact on our Active Directory. The only impact from a problem would be at the Azure Active Directory level.

Deploying Entra ID is generally straightforward. Once we create our Entra tenant, we gain access to Entra ID. Similarly, if we subscribe to Office 365, Entra ID is automatically created for us. This default setup meets most basic operational needs. Therefore, we don't typically need to make any further configuration unless we want to adjust security settings based on our specific organizational needs. Overall, using Entra ID is seamless and can be started directly from our tenant or Office 365 site.

I was not involved in its deployment.

In terms of our environment, it's a private cloud. We have the infrastructure within the platform, but all the software, all the usage, and other things are handled by us. We're private because we're a big company, so we're able to afford it. We're not an IT company, so we don't need so much processing power. So, we use Azure as a PaaS solution.

We use it as a connector for different applications. We have Adobe Sign and applications on AWS. AWS has a translation solution, and people have accounts over there. They have their translations of different products and things like that. That's how we use it.

In terms of maintenance, everything is done by Microsoft. We are just the end users.

The complexity of the initial setup depends on the technique used. While it may seem a bit complicated, with the proper design, it becomes a non-issue. Each module has different procedures. For instance, the Defender module, which is a Microsoft service, serves as a part of the Entra ID, allowing us to block and control websites and provide security antivirus solutions. We have onboarded all our devices to Defender. Thus, the machine doesn't need to be part of Microsoft Entra ID, but migration is still possible.

Currently, we are in the midst of a project to onboard the devices to Microsoft Intune. We are transferring the devices from the local active directory, and this process is ongoing. For each device, specific scripts need to be executed, which can be a bit complex. The complexity often arises due to existing policies and applications. When everything is well-prepared, the onboarding process is smooth. This might be an easy task for a new organization, but for those already using a different solution, the migration process becomes a bit complex. Thorough testing is necessary, especially considering that policies tend to change over time.

This project has been running for more than two years and is still ongoing. The pilot phase alone is estimated to take about one and a half years due to various commitments. Unlike a company like Google, my organization operates differently; it encompasses multiple entities like the United Nations across various locations. Since the user count exceeds five thousand, we're being cautious and gradual in our migration. At present, we have migrated only around a hundred users for testing purposes. The migration of the remaining users is scheduled to occur soon.

The initial setup was straightforward. We had Microsoft's support within our company, and the local provider in Mexico was very easy to use. We only used this part for Microsoft 365. Connecting with our MBM provider was the same process and easy to do due to all the documentation; we simply followed the steps.

One person was used for the deployment.

When you set it up the product, there's always a combination of business people, decision-makers, and IT people, and I always encourage business and decision-makers to read the Microsoft adoption framework for Entra VNS Ready. So that way the decision makers have an idea of how to use the product and which features are required. Then we start with the technical part. 

We should basically start always with an assessment. How many users do you have? Which one is the office license model? And so on and so forth. When the assessment is done and when we have an idea of the topology of the user, we can start the design. We ask, okay, would you like to be cloud native? Would you like to have a hybrid model where you have an on-prem identity shipped to the cloud? And based on the decision, we'll start by usually setting up Azure AD Connect. 

Azure AD Connect is a solution that's on-prem. We'll onboard the identity on the cloud and all the security tokens that come with it. Then, of course, we start to plan the identity migration.

Based on the call on existing users, the next design is to onboard a lifecycle identity for the new commerce that will join and for people that will lead. It's important to read the Microsoft architecture and adoption framework for InsightID. And based on that, then we go into the nitty gritty technical decisions. 

The setup can be handled by one person. However, once you begin to integrate it with 95% of the organization and need to touch messaging systems and mail systems, you'll need to collaborate with others. If you are using the Internet and SharePoint, you need an Internet engineer. You likely need a few people to assist.

The maintenance aspect is not difficult. It's a SaaS and Microsoft handles most of the burden. You just need to perform hygiene rather than maintenance, for example, removing people you no longer need. While maintenance is mostly taken care of, people should pay attention to the Azure cloud as Azure can cause security holes with changes. 

I have been working with cloud and hybrid deployments. There are a few cloud deployments, but I work a lot with hybrid deployments.

Its setup is straightforward. I am very used to it now, and for me, it is pretty straightforward. The deployment duration depends on the features that you want to enable. Features such as conditional access require discussions with the customers. Generally, two weeks are enough. You might also have to train the internal team on it, which could take a bit more time.

You do not require too many people for deployment. One or two people are normally enough.

In terms of maintenance, it is very easy to maintain. You might have to add another business case for your customers or simplify something you put in place. You have to be aware of the new features, etc.

The initial setup was straightforward. 

The initial deployment is easy and not complex. It took us about a month.

It was initially on-prem, but later on, we shifted it to the cloud. When I joined the organization, it was already on-prem, and I helped to shift all the data from on-prem to Azure cloud. The process was a little complex. We had a few on-prem issues, and we had to redo the capability testing to check if those issues will arise on the Azure Cloud as well. It was complex because we were again asking some of the users who had changed their phone numbers to go and re-add their phone numbers. If they had the same phone number, it would have worked fine, but if they had changed the phone number, once it is shifted from on-prem to Azure Cloud, it wouldn’t have worked anymore. So, they had to re-add their phone number. The challenge was to identify those users and convince them to redo the activity. This switchover took about two quarters or six months.

The deployment time depends on the knowledge of the engineers and the cloud approach. Therefore, it can take from a few months to a few years, and sometimes it may result in the provisioning of everything because of a gap in knowledge of the people deploying. I have seen really bad deployments because the people were not cloud-ready.

Entra isn't too difficult to set up. We follow the Microsoft cloud adoption framework. There's a phase that involves aligning with best practices and making sure it's secured appropriately.

I was involved in the original deployment or initial setup of Microsoft Entra ID in my organization, and we found it to be a complex process. In the past, my organization was involved in the migration process from a custom Oracle-based solution to Microsoft Entra ID. Microsoft Entra ID was a product that was a new acquisition for Microsoft at the time, in which some custom development work by our company's team was required.

The product is used for our enterprise, an academic medical center with many different hospitals, owing to which the tool is deployed centrally.

The solution is deployed on hybrid cloud services offered by Microsoft Azure Cloud.

We're using Azure Active Directory with Office 365, which is a public cloud. The same Azure Active Directory is integrated with Azure infrastructure's private cloud, so the same Active Directory is serving in multiple scenarios. Through the same Azure Active Directory, we have integrated with the custom applications that are hosted on other public clouds such as Oracle Aconex, SAP S4HANA, SAP Ariba, SAP SuccessFactors, and Tejari. So, we're using it in the hybrid mode to sync our local Active Directory. From that hybrid mode, it's providing authentication to the users for Office 365 and it's providing services for the users who are using Windows virtual desktop. On the other side, for the third party, we're also using Azure Active Directory.

I deployed it myself. The initial setup was complex when we were implementing it around twelve years ago, but now, it's very simple. When we started this journey, it took us six months to integrate our local Active Directory with Azure Active Directory. We worked with three different partners. Two of them failed, and then Microsoft Pakistan got involved with us. Through their Dubai-based partner, we successfully integrated our Azure Active Directory with our local, on-premises Active Directory. We got success with the third partner, but overall, it took us six months. Nowadays, the hybrid configuration and the integration of Azure Active Directory with the local Active Directory is a piece of cake.

In terms of maintenance, because it's software as a service, Microsoft is managing it for us. We don't take any backup, etc. It's just managed by Microsoft.

We were not involved in any deployment. It was automatic. The moment we signed in, we were part of Azure. It was straightforward. We just purchased our license, logged in, and we were automatically onboarded to Active Directory seamlessly.

It doesn't require any maintenance. It's managed by Microsoft.

Setting up Azure AD was straightforward. It's all delivered online, so it's only a matter of filling in the parameters for our organization. After that point, it scales easily.

There's no traditional maintenance. We have to perform audits on accounts to ensure that people and permissions are still online. There isn't product or data maintenance. 

The initial setup was straightforward.

How you plan the tenant and set it up is quite key. There are major components that you need to be aware of: 

• Are you planning to implement multi-factor authentication at the tenant level? 
• What type of conditional access policies do you want to implement? 
• What type of access governance do you want to put in? 
• What type of role catalogue do you want to maintain? 
• What type of structure of the AD organization you want to maintain? 
• What type of device registrations do you want? 

There are some prerequisite checklists available from Microsoft. However, these are quite fundamental decisions. If you don't take the lead on them, these decisions will impact you, then you have to go back and fix them later on. So, plan ahead. 

Initial deployment took us a few months across our organization, but we decided to use most of the elements at a very early stage. So, our use case could be different than other companies. Some organizations that I know have chosen not to deploy multi-factor authentication nor do self-service password reset to deployment, then the user community is impacted with that. It can differ organization to organization based on the scale, number of users, locations, etc. So, there are many factors involved. 

We phased out our deployment over a couple of years, focusing on single sign-on and multi-factor authentication, then self-service password reset and other components. So, we did it as a phased deployment with a small team of four or five people.

Deployment time really depends on how you set up your Azure AD. You might: 

• Want to set up Azure AD Connect, then the process takes longer. 
• Just use Azure AD, then the process is much faster. 
• Directly connect to another source of truth, then there is something in-between. 

It really depends on your situation. I would say it takes between an hour and a week.

We obtained certification for the deployment of the solution. Microsoft provided a document outlining all the deployment rules and steps, as well as a planning team that provided instructions for all email templates. The deployment required three people.

The initial setup is easy. You just download it and start using it. 

We don't need to worry about maintenance. This is a service from Microsoft.

It was very easy to get set up and running. Basically, you log into the Azure portal, you have your tenant that you're already connected into, you add a domain and then you just go. You add your first user and then you continue from there.

Our deployment started in October of that year, we had our first users within a week, and then we pretty much provisioned all of our users within a month. It was a pretty quick turnaround.

At the time of deployment, we were in the middle of a divestiture. As such, our implementation strategy included spinning up a brand new Active Directory so that we could start to migrate our users over from our previous owners into a new one that we would control. Consequently, we started from scratch.

I know that a lot of companies are not doing that. Rather, many are starting with an Active Directory and then moving into Azure Active Directory, but for us, it was a clean slate. We then started to incorporate methods of synching with our previous owner so that we could get all of the data from them and continue to march towards a separation.

I was not directly involved in initial setup tasks, however, when they migrated the user's object from the local active directory to the cloud, then we used a third-party tool called Cluster Migration Manager, and we used the tool to migrate the object user and object functionality to Azure.

We have continuity load balancers and we have also deployed VMs and SQL databases. we've configured a lot under this product.

The initial deployment was straightforward, although we initially found it challenging to understand how to use Azure AD to manage access and permissions with external parties. We carried out the setup using three staff; myself and the IT team.

The initial configuration is simple. The configuration process is guided so that even a non-technical person can successfully complete the onboarding.

Setting up Azure Active Directory was a bit complex. The migration process is somewhat challenging because we don't want to lose any on-premise data. Each user has many parameters and access policies already set. Without even changing the password, we were able to sync all this data to Microsoft Azure AD. It was a complex procedure because Azure AD Connect has to be deployed correctly. We required help from Microsoft's technical support to do this.

Our initial deployment required three system admins and took around one week, but it took around six months to import all our users and get everything working properly. After deployment, Azure AD doesn't require any maintenance because everything happens in the cloud. We don't need to bother with anything.

There were a couple of hiccups along the way, but the initial setup was fairly straightforward.

The biggest issue for us was getting the sync working from on-prem to the cloud. That was the hardest part. As far as the deployment itself, we went and created an Azure tenant and then created the Azure AD or a portion of it. After that, setting up the sync was really the biggest part.

I have set up test environments. The setup is easy, not difficult at all. This is one of the solution's strong points.

A lot of people already have on-prem Active Directory. It is a natural step to extend it to Azure.

Compared to other products in the market, the Azure AD deployment is the fastest. Depending on the size of the organization, it could take weeks or months to deploy.

The initial setup is straightforward. The deployment required around six hours. I only had to import to write the existing users into Azure.

I wasn't involved in the deployment; the solution was already in place when I arrived. It doesn't require any maintenance that I'm aware of. 

The initial setup is pretty simple. Microsoft Azure AD can be deployed in one or two minutes.

If you have an Office 365 subscription, Microsoft will build Azure AD for you.

Its initial setup is very easy. We had to do policy configuration and user configuration. That was it.

It does not require any maintenance from our end.

The initial deployment was straightforward and took two months to complete. We switched over to the new system and then set up a number of additional features, such as enterprise applications and multi-factor authentication. This took an additional month, for a total of three months. We followed the instructions from Microsoft step-by-step. The deployment required two full-time employees from our organization and three from our partner.

The initial setup was straightforward. The time required for deployment will vary depending on the features that we plan to use. Typically, two to three weeks should be sufficient for deployment.

The initial setup was straightforward, and a partner was present to assist us during the implementation. We have around 250 users, and the solution doesn't require any maintenance.

The initial setup was not very complicated because there are very good articles online, published by Microsoft. They give detailed steps on the process and including what challenges you may face. In our setup, the articles online were sufficient but suppose you run into any issues, you simply reach out to Microsoft for support.

Taking the purchases, planning, and everything else into account, it took between three and four months to complete the deployment.

I was not involved with the initial setup but I assume that it was not complex because we have Microsoft consultants assisting us.

The initial setup was so straightforward. The documentation is good. There were no problems deploying it. We did the deployment for one customer in less than an hour. Another customer took some time because it is more like a process for change management. Otherwise, the actual installation, download, and configuration took less than a couple of hours.

My previous company's focus was on how to integrate a customer's Active Directory with Okta, how to integrate it with MFAs, and how to integrate with security IMs.

The deployment was easy to do and integrate with on-premises. So if it was a small- or medium-sized customer, we could bring them into the cloud in no time. Also, we could start looking into other applications that the customer could use: Docker containers or DevOps. This is where we spent most of the time, i.e., with customer design.

Every hospital with Office 365 comes with Active Directory Domain Services so you need to sync all your users. That is how the implementation is done today.

The initial setup is not a complex process. It is simplest in a cloud-based deployment and it will not take much time. If your current server is on-premises then you only need two things. One is your enterprise domain users, which have full access permissions. The other is a global administrator on the cloud side. Both sides need to be integrated and this is done with the help of Azure AD connect. Once this is complete, you can have interaction between your on-premises data and cloud data.

It is helpful to have a basic level of understanding of the product prior to implementing it.

I was involved in its deployment. It was complex, but that was not Microsoft's fault. That was our fault because we have a very complicated environment.

We have a hybrid environment. We were in IBM, but we pulled back. We have Oracle's cloud platform, and we have AWS as well as Azure, but 99% of our cloud workloads are all in AWS.

When we initially started, Microsoft was not there. The initial implementation strategy was to synchronize the Windows Active Directory corporate domain to Entra ID. That way, we had the identities and we could use the same AD connector to synchronize the AD distribution lists. The other side was the mailbox. 

We did not take the help of any integrator. It does not require much. You stand up your servers. You have a staging host with its own database, and then a sync host with its own database. You then hook them up and make sure you have all the permissions in your previous tenant.

Microsoft puts MSOL accounts in some default directory. You should be able to tell the agent to put the MSOL accounts in a more secure OU. For instance, the original recommendation, which has changed recently, when we set up the service was to use an enterprise admin to set up the agent, which generates a bunch of MSOL accounts. Those MSOL accounts ended up in our all users' organizations. When you have a company of our size, that is not the only MSOL account that exists in the directory, and it is really hard to tell those apart, so we have to look through the logs, see which MSOL account it is using, and move it into the proper OU for the on-prem domain. It would be nice if you could determine where that goes at the time of creation.

The Active Directory just plays a role in authenticating the user, and it doesn't do anything else, just authentication. The services where the deployment is being done, that is a different thing. It is an application service in itself. We have an Azure Active Directory service. Besides that, we have application deployments or application services on Azure as well. That is a separate service, which is used for the deployment of the application, so when a user is accessing the application, he is redirected to the Microsoft Azure authentication application where the authentication is being performed. So far, the authentication has been performed, and that user is being redirected to our actual application, which has been deployed on the Azure service. Therefore, there isn't really a direct deployment per se for this product.

The ease of setup depends on the scenario and the use cases of your organization. 

The initial setup was completed by a separate team.

We have five global administrators who are primarily responsible for providing access and assigning roles for all the various different groups and teams that have different subscriptions, and they will manage their subscriptions based on the roles that they are assigned.

In terms of deployment, Active Directory ensures that there is express route connectivity from an on-premises data center to Azure and ensures that there are sufficient redundancies in Azure Active Directory Connect Servers and Domain Controllers. 

I was not responsible for the initial setup but my feeling is that it is not very straightforward. From a technical perspective, I expect that it is somewhat complex.

The deployment took approximately six weeks. We are a large company with more than 60,000 employees and I expect that for a smaller company, with perhaps 100 or 200 employees, it might take a day or two to complete.

The initial setup would have been complex if it had not been for being part of the GTP program. We have gotten a lot of value out of that program in terms of cross-training our team members, catching up on any new features that come out as well as any of the gotchas that the Microsoft team has seen. So, those have benefited us quite a bit.

The deployment probably took six to eight months. Standing up Azure and sinking your directory services, like creating a connector, takes minutes. We could stand that up in the day. What took time was taking all of the applications that we have throughout the environment, migrating them across and doing integrations with single sign-on. You need to have conversations with different application owners as well as potentially pulling in some vendors to do some of the configuration. There may be some apps which are not as straightforward as others, but we thought that the experience was pretty straightforward (to a point) where we can handle a lot of the work ourselves.

I was involved in the deployment process. It's easy for someone who's done it many times. 

In my department, we have ten to 15 colleagues that can handle these migrations or synchronizations. 

It's an easy product to maintain. 

The initial setup is straightforward. There is nothing very complicated about it.

The very basic setup of AD might take between 10 minutes and half an hour. Then, if you sit down and focus on the task, it takes about a couple of days to have all your nodes in place.

In our company, there is another person who is my immediate junior and who reports to me. We are the ones who deploy, use, and maintain the system.

The installation is easy. You can do the installation on mobile phones and it can be installed on the web. It's not a problem.

The deployment is fast and only takes about two minutes. It's supposed to be done by the end-user.

They've done a good job on OIDC. That was a pretty simple, seamless setup. We've done that with multiple remote IdPs now, and I don't recall too many issues there.

The initial setup was very straightforward. The documentation is very good and the steps are very well documented. I remember three years ago I encountered some undocumented feature or maybe a bug when configuring Azure AD for apps registration. However, lately, this is not the case. Currently, the documentation is very up-to-date and very clear, and almost every time I register the user, the apps in Azure AD, and configuration the Azure B2C have helpful documentation. They probably made some form of an update to the system that fixed any past bugs or issues.

The deployment hardly takes 15 to 30 minutes - and that's for app registration. To complete the whole process on the Azure AD side and on our Dynamics 365 side - including Azure B2C - it took, when I implemented it for the first time, one hour to set up everything. That was the first time. Since then, I've gotten faster and it now hardly takes 30 to 40 minutes to configure Azure B2C.

It is a predeployed solution, creating the links between the on-premise system and SaaS system is moderately easy.

Our deployment took a month.

For a non-complex organization, the deployment process would be a lot easier than it is for a complex organization. There are a lot of business processes that need to be determined as well as a lot of conversations. The technology side of things is the easy bit. It is the design that takes awhile.

The initial deployment was straightforward for me because I already had a pretty good experience managing the on-prem Active Directory. The deployment of the directory itself does not take long. However, it took us about a couple of months to carry out the user creation, create the Conditional Access policies, and to test. You have to test your policies before you go live. We had a lot of design to do in terms of setup, testing, rollout, and setup for each feature that we needed to implement. We had more of a test phase before the go-live phase. That's why it took quite a while. 

It is easy to deploy and not complex, but it also depends on your requirements. We have tenants and subscriptions, and we connect AD to Azure AD through Azure AD Connect, and they are periodically synced.

The connectivity took a day or two. It doesn't take long. Sometimes, there could be issues with on-prem because of not having a standardized setup or because of parameter duplication, but after we resolve the issues, it doesn't take long. For its setup, only one person is generally required.

The initial setup is straightforward.

The initial setup was quite straightforward. It didn't take too long just to get our Azure Active Directory environment set up and running. I think it took less than a day. It was really fast.

We already had Active Directory on-premises, so what we created was the instance of Azure Active Directory. All the different groups, users, and services were already set up. We then replicated with what we currently have in the Azure Active Directory instance. It was not really difficult.

Our company is quite small and that is reflected in our IT department. Azure Active Directory is handled by our infrastructure coordination team, which has only two members. One is the senior engineer who performs all the major changes and the main configurations. We also have a junior engineer who runs all the operations in the company. From time to time, one person from our help desk, usually me, does some small operations when we don't have the infrastructure team available.

The initial setup is straightforward. We downloaded it from the Google Play store and used a name and password. That's all it takes, and we're ready to go. The configuration duration is set on an admin site, but the actual configuration must be done on the end devices themselves. This can include mobile devices, tablets, or any other device that we can use, and takes about ten minutes to complete.

The deployment is quite straightforward. It's truly uncomplicated from an IT perspective to utilize Microsoft Entra ID. It's not overly intricate in that aspect. However, when we delve into end-user scenarios, and the management and configuration of conditional access policies, permission management, and other similar aspects, it does introduce a certain level of complexity, naturally.

It is a very easy process to set up. First, we need to collect all the information, e.g., the custom domain information, user information, and which kinds of applications the users want to access. All this information is needed. Based on that, we can just set up and go to the Azure Portal. We can go to the Azure Active Directory console from there, where we can verify the domain and do the management. It is a very easy process, which is not time-consuming. Though, if you want to design your own application (customize it) and provide access for a particular user or group, then it can be a bit of a time-consuming process.

As the product already existed before I joined my current organization, I was not involved in its deployment phase. I have some past experience with the deployment processes of Microsoft Entra ID and Microsoft Active Directory. The deployment process of Microsoft Entra ID was easy, and it is not anything different or terrible.

The time for deployment of the tool depends on the client or the project my organization deals with, and a lot of the clients I have worked for are pretty small teams. I haven't had to do too much in terms of deployment.

I have played a small role in deploying Azure AD, but I have not been involved in the migration process. Overall, the deployment is easy. It took us 20 to 25 days, including fixing issues. That was normal, nothing unusual.

Regarding maintenance, the team I'm on does application maintenance. For Azure, we have a cloud admin who looks at the Azure portal for things like billing, access management, and admin work.

The setup was straightforward. We made an implementation plan and transitioned from using MFA via email and SMS messages to using Microsoft Authenticator.

Our security team is responsible for all our security solutions, and they take care of the maintenance, which I understand to be relatively light.

We have a Security Operation Center in our company. Another company using the same solution without a team like ours may require several hours a month to manage the solution.

The setup was pretty straightforward. In terms of maintaining it, we have a team of six infrastructure engineers, and Azure AD is just one of the systems that they manage.

The trick was to immigrate from LDAP. We had to get all the properties from the files into Active Directory, so it took some time. When we did that, there were some issues with the system and we had to do it manually. It would be nice if they had a service that would make it easier to migrate from LDAP to Active Directory, keeping all of the properties from files and non-structured data as well.

We've been doing implementations for a while now so for us the initial setup is straightforward. It becomes complex if a company is coming from a complex environment in the beginning, however, nowadays it's straightforward.

While planning, the first thing we do is an assessment and then we go to the design phase from the assessment on what the company has. Then, from the design phase, we designed the Azure infrastructure and do the implementation. The first thing is, of course, the identity. In general, deployment takes two or sometimes three months.

I'm a user, administrator, and contract negotiator for Microsoft Authenticator. I'm also part of the implementation team, and I found the initial setup for this tool straightforward. It doesn't require an advanced level of technical knowledge, and it took around three to four days for the complete implementation and deployment of Microsoft Authenticator.

The solution's initial setup is fairly straightforward. The biggest issues we had were syncing it to the on-premises Active Directory and doing local things like RADIUS.

The initial setup was straightforward. The client has got three people working for him.

The setup is mixed; the startup is fast, but configuring requires the knowledge of a consultant or technical resource. Basic deployment can be completed in a day, but our greenfield deployment took a relatively long time as we're a large organization. A greenfield deployment should take at most two weeks, but implementing Azure AD into a functional environment is a project unto itself. It could take months, depending on the use cases.

Regarding maintenance, we're a global organization, and each feature has its own operating team. At our scale, a group of 25 is responsible for managing and maintaining the identity part of the solution.

I was involved with the initial setup, and it was straightforward. No high-level programming was required as it is a UI-based solution.

Microsoft takes care of the maintenance; it is a fully managed service.

Due to the fact that we have a hybrid architecture, not a clean cloud solution, it took us a lot of time. We had to consider how everything, all the applications, was going to work. Active Directory is also involved in emails and there were many procedures to consider and test. There were also many users who were staying on-prem. We also had to consider external cooperation with other European and domestic energy companies. So it took us about one year. Our company is not a simple company, like a sales company or a manufacturer. We deal with critical infrastructure and we have to control and operate the power for the whole country. We had to think about every step of the journey.

We had 10 to 12 people involved. I was the project manager and there were three groups of people, in addition. One was from telecom and security. There were a few people from infrastructure and technical support, and there were some people from the application side, to test that all our applications were active.

We also have teams for projects, like when we do a large construction for something like power lines. We form teams between departments and these special teams may work for a year on a specific project. We also needed to consider them because they have different needs and work from different places and are mobile.

Because we have on-premises firewalls in our company, we had to do some work before we implemented AAD to arrange access between the company's security system and the Microsoft cloud system so that they could cooperate and communicate. We had to open the protocols, et cetera. As a result, we don't have any problem with the consistency of our security policies.

In the beginning, it was a matter of getting used to the procedures. We needed to explain things to the users so we sent them a guide. We rolled it out to our 2,500 users in many batches over about four months.

There is periodical maintenance, such as upgrades, as well as ad hoc maintenance. For example, if we modify public folders, we need to do some work because, on one occasion, cloud users couldn't see a public folder that was on-premises.

It is straightforward for the admins, but end users hate it. On the admin side, it takes 20 minutes at the most.

The Authenticator app wants you to have all your prerequisites designed for whatever environment you want. If you're going through Azure, you can pick the particular applications on which you want this. You can also pick the users for whom you want it to be effective. You can pick the type of ways they authenticate through the Authenticator app. Those are the simple steps.

One person is enough for its deployment and maintenance. I do that. That's not even a role. It depends on who you are, but that's not a role. That's not something for which I would employ a person. I wouldn't employ an IT person or an administrator just to focus on this.

We received the migrations as a direct value add because we are a part of Microsoft MSP.

The Azure Active Directory migration took ten days to complete.

This solution is maintained by a team of three to four people.

The solution has been straightforward to set up. It's simple. It's not overly complex. 

We have a handful of people involved in the initial setup. You don't need very many. They are mostly specialists and technicians. 

The initial setup of Azure AD is very straightforward. There is even a wizard for it, making it very simple. The wizard guided us and pointed us to articles in the Microsoft Knowledge Base, in case we had any doubts about what was going on. It was a matter of "next, next, and finish."

Deployment took less than 60 minutes. It was very fast.

There are almost always issues when it comes to synching on-premises instances because they almost never follow best practices. When migrating to the cloud, there is a tool that Microsoft provides to run in your environment that tells you, "Hey, you need to fix this and this about these users, before you initiate the migration." It's complicated because on-premises solutions are like that. But if you want to have identities in Azure AD, you must have a proper set of User Principal Names, because these will be the anchor for the synchronization. If my on-premises instance has a bad UPN, it will not be able to properly sync to the cloud. But once we finished fixing the irregularities in the on-premises accounts, the migration was easy. We just installed the synchronization server and it did the job.

Setting up Azure AD, is about moving toward the cloud journey. I cannot say setting up Azure AD is easy, but on the other hand, organizations are not moving to the cloud in one go. It's not all or nothing, that you have it or you don't have it. It depends on which services you are receiving from Azure AD. Some organizations, like ours, start with a limited number of services.

You usually start with syncing your identities to the cloud so that you can offer your employees certain cloud services. You want to enable them to use certain SaaS applications, where they are relying on a cloud identity, and that's why you need to have your accounts in the cloud. Without that, you cannot grant them access.

Later, you may offer the ability for business partners to use and benefit from certain cloud applications, and gradually the use cases increase. For example, someone may become a privileged user to take responsibility for an application and manage it. When that happens you start to think about what other features in the Azure platform you can offer to do administration in a more secure way. Or, once you have thousands of users benefiting from cloud applications, how can you make sure that you protect their assets and their data? That leads you to start implementing other security features, such as multi-factor authentication. Over time, you may have users benefiting from Office 365 and they need to collaborate by using Teams and SharePoint. Again, you start to build something else around that.

Whether large or small, organizations are on a journey, where they start from on-premises with servers and all these server rooms and applications in the organization. They then shift workloads to the cloud. That process is still ongoing in my organization and in many organizations. Ten years ago, workloads were all on-premises. Five years ago, maybe 90 percent were on-premises. Today it might be 50 percent cloud and 50 percent on-premises. There is value from the cloud: elasticity and flexibility, even for big organizations. A server on-premises is a different story compared to having it on the cloud. If I need to upgrade a server on the cloud, it takes five minutes. If it's on-premises, I need to order hardware and then change the hardware. The usage of Azure Active Directory is due to the evolution of the cloud.

The bottom line is that the implementation is gradual. It's not difficult or easy, although we started with things that were easy to adopt, and then we continued the journey.

The staff required for maintenance of Azure AD depends on how you organize your support. Some organizations outsource their end-user support to other companies, while other organizations staff that completely internally. It can also depend on the users. Is your organization a global organization or a small, local organization? For us, to make sure we maintain the support and availability and all the services we need, including change management, we need at least 15 to 20 resources for a global application with more than 20,000 users, to maintain the platform.

The initial setup is straightforward. 

Active Directory is a place where all your instances, users, identities are being stored. You can create users and identities, then they are stored in Active Directory. Then, Azure Active Directory is just like a cloud-based scenario. When you create users, they are there. You can join devices to your Active Directory.

You need to have the user's information: their password, email, location and ID. All those things are being stored in Azure Active Directory. 

Deployment time depends on the scope of work. For example, a single user could take about 10 minutes to deploy, if you know what you are doing.

The initial setup is not that complex. Maybe I'm the wrong person to ask, though, because I am already an old AD person and I understand it.

The initial setup was complex, but we overcame the complexity. 

Setup was very simple initially. Deployment took no more than six weeks, and we only needed two people.

The initial setup is simple.

It is pretty easy to set up the product. You subscribe in Azure Active Directory. By default, it will have an extension where you need to register. If you need a custom domain name, then you need to register with your public DNS providers to create the DNS public entry. You will then have to prove that you own the domain name. Once it has been proven, then your Active Directory pretty much works. 

If you need to sync up your on-prem users with the Azure Active Directory, then you need to have an AD Connect server installed at the VM-level domain. It should be credentialed so AD Connect can use credentials to read your on-premises and sync it to the cloud. Once this has been done, you are good to go. As an enhancement, for whatever user you are syncing, you can mandate them by adding them to a group or rolling out an MFA policy.

The initial setup was straightforward. When I set up Azure Active Directory, I just had to create an Office 365 tenant.

Creating an Office 365 tenant automatically creates an Azure Active Directory organization for you. For example, if I create my user in Microsoft 365 automatically, I see them in Azure Active Directory. I just need to go to Azure Active Directory, set up my policies, and whatever I want to do based on the documentation.

A part of the documentation is actually complex. You need to read it multiple times and reference a lot of links before you can grasp how it works and what you need to do.

The very first time, it took me awhile to set up. However, when setting it up the second time, having to create Azure AD without setting up users was less than three minutes.

It is very easy to configure if you are configuring a completely new cloud deployment. But with the on-premises deployment, there are some difficulties due to security issues, like credentials required.

It doesn't take more time to install AD Connect on-premises. The installation itself takes one hour and, within one to two days, we can take all the data over to it. But we then need to monitor it for at least two days to make sure everything is fine.

We have almost 400 users in our AD and we have six people involved in maintaining and administering it, including me in my role as senior IT engineer. I take care of Active Directory monitoring, as well as installation and configuration. We also handle patches and upgrades. One person takes care of the billing part.

It was in the middle of the road. It was not the easiest thing, and it was also not the hardest thing.

The tool's deployment is easy. However, documentation is not helpful. 

I was not involved in its deployment. 

The initial setup was very straightforward. We've worked with Azure Active Directory for the last three or four years and find it very easy to deploy. It might take maybe three days. 

In terms of maintenance, we only have a couple of people dedicated to offering technical support. Once you deploy it, it's not necessary to give too much support after that.

The initial setup is not very difficult, especially if you start using it straight away. But if you do the migration, I think that might be a challenge. Fortunately, we started directly from Azure AD, we didn't have to do any migration from Azure AD On-premise to the cloud. It was pretty straightforward and easy. We didn't face any difficulties.

For the initial setup, we mainly followed the tutorials that Microsoft has online. Initially, it was a little bit confusing because we discovered that there are many different versions of this same software. There are distinctions between an on-premise way of doing things versus a hybrid approach versus something that is on the cloud exclusively. There are limitations that each one of them has, as well as other differences that include mobile versus desktop solutions.

For a newbie like me, it was a little bit challenging to understand what the best approach would be. In this case, we were oriented by the teachers to implement the hybrid approach. When we were configuring Azure Active Directory for this, and also for the organizational units, we used the Bastion service. It is the one that creates the domains.

The deployment took perhaps half a day to complete the configuration, step by step. We had to make corrections between configurations, where we had made errors, which was part of the learning process. Overall, when you really know what it is that you have to do, it's pretty straightforward and quick to complete. Otherwise, it will take you a little bit longer.

From the documents that Microsoft has available, we understood that there are several ways to deploy this solution. There is an on-premises version, a cloud-based SaaS, and a hybrid option. 

We were using virtual machines with a license that was connected to our educational package. We have a product key, install it locally on the virtual machine, and that's how we worked with it. At that point, it was connected to the cloud.

Our Azure accounts are related to our college email address, and they are also administered by Active Directory.

The deployment process involves using the Azure AD Connect tool, which is very important. The only choice that needs to be made beyond this is whether you want to have single sign-on (SSO) enabled or not.

The deployment will require some basic planning. The length of time required will be a maximum of four weeks. Three staff should be sufficient, although this depends on the number of users.

I was not a part of the implementation. It was done before I joined the company. 

It may require a bit of maintenance, however, it's not a task that is part of my department. 

Installation is straightforward. It only took a couple of hours to set everything up.

Installing this solution was seamless, but it took time for it to complete. It took one month.

In my previous organization, I was involved in the implementation and it was very straightforward. It was straightforward in the sense that we didn't encounter any major issues because we were already using Windows Active Directory. The only issue we had was that we had to move people in batches, and not at the same time.

Our deployment took approximately one month.

As part of the implementation strategy, we first moved our Exchange to Office 365. This was the initial migration of users from on-premises to Azure AD. The primary phase was to start using Office 365 for our email instead of Exchange.

The initial setup was complex.

We have half a million users from 20 different offices. They've all got different ways of wanting to do things, including the way we have to build the federation infrastructure, for example.

This has been a four-year project, and we're probably going to continue with it for the next year or as long as we'll be using the product.

The initial build we did was a six-month build.

Our implementation strategy was to delegate sections, including delegating identity and federation setup.

We have five full-time personnel that handle the maintenance aspect of the solution. We have outsourced the actual hands-on maintenance. This firm has a couple of engineers, an architect, and an engagement lead. We have three solution delivery managers on hand, however, they do other tasks as well and are not necessarily dedicated to AD.

When I set it up two years ago, it was easy, not complex. It didn't take much time at all to set up.

A lot of people sign in or set it up with a Google account, Yahoo account, or Microsoft account, which is not the global administrator. A lot of people think that this is the global administrator. They don't understand that the account might have an extension and don't see this until that account gets locked out. That is when they have problems signing in. The setup is not that complex. It is just that the user experience overall needs improvement here.

The deployment process depends on what you are trying to achieve and the technology that you are trying to deploy, e.g., are you trying to deploy SSO, set up device writeback, or do a regular AD Connect setup? Everything depends on the objective or the overall goals of what you want to achieve.

The initial setup is a straightforward process, for such a complex technology. Although there are a lot of moving parts involved in actually setting it up, it is quite easy.

I've set this up for many and, in general, it takes less than a day to get things up and running. Then, of course, there's tons of optional configuration to improve and secure things, but just getting it up and running takes less than a day.

The implementation strategy used to be helping them get to the cloud, by doing things like making sure that they clean up the accounts in the on-premises solution and setting up the synchronization rules. But nowadays, most of my customers are people who have Azure AD in place already. So now I'm trying to enable and configure and improve security configuration. For example, you don't have to set up the passwordless feature and you don't have to do multi-factor authentication. They are optional. So my task now is more one of improving their configuration and turning on security features. A lot of it is secure by default, but some features require you to configure and set them up.

I was not involved in its deployment in my current organization, but I was spearheaded into bringing from a basic use case to a lot more security and a lot more automation and manageability.

Initially, the initial setup was very basic, and then we modernized it and improved it. We used a lot more policy, and dynamic user groups were a big aspect of that single sign-on in the app management, app registration, and various other aspects.

The difficulty or ease of the initial implementation depends on the company and the level of experience as well as the level of knowledge of the IT team. The experience needed for cloud solutions is relative. I can say it's straightforward and even with a little experience or knowledge it is straightforward. The documentation is available and you can read and follow the documentation to handle the process. Of course, for new users, it could be a bit more straightforward.

For me, provisioning takes a few minutes - maybe between ten to 20 minutes. Normally it should take less than 30 minutes.

For this particular instance, we needed to add multiple users individually and sometimes as a bulk upload in the case of inboxes. Some needed third-party services. The documentation made the process pretty easy, however, when we did have issues, we could reach out to technical support to finish anything up. 

The initial setup was straightforward. It does not require any maintenance. 

Setting up Azure AD is straightforward. 

I wasn't involved in the initial setup, but the solution is straightforward to use once installed. 

The solution requires a little maintenance, as we sometimes encounter bugs where the app doesn't recognize a user account, for example.

Setup was straightforward. Implementation took three months.

For the deployment process, we had a technical team of two people who did everything. They are engineers.

The setup is effortless because we've been using this solution for a while. We are familiar with the setup now, so it's easier.

The initial setup is very, very easy. It's not complex or difficult at all.

Considering that it runs on the cloud, the setup is quite easy unless you're doing integration with your on-prem Active Directory. For integration with your on-prem Active Directory, you need someone who is technically competent, and then it would be rather straightforward. They do provide engineers who can assist in that deployment, and they also do knowledge transfer to enable you to proceed with the deployment.

The initial deployment of the product usually takes about three months because you have to ensure all the prerequisites have been met. So, if it is a project for a big organization, we can do it in probably three months. If it is something simple, then it doesn't take much time because the only thing that you're doing is to plug into it. It is already running because it is a cloud service. So, the deployment comes in only if you're integrating it with your on-prem resources and, of course, with other applications. Otherwise, it is very straightforward. It is a cloud service, so it is just plug-and-play.

It's pretty straightforward in general, although it depends on what kind of requirements a client has.

If I'm deploying with Microsoft Autopilot, it usually takes at least 40 to 50 minutes to deploy one machine. If I'm deploying 1,000 machines in one go, you can multiply that 40 minutes for each of those 1,000 machines. Everything is configured in the cloud, in Azure Active Directory. You just need to purchase the machine, configure things, and ship the machine to the user. When they turn it on they will be able to work on it. Everything will be installed in the backend. If it's not on Autopilot, it's just in a matter of a few clicks to connect the machine to Azure Active Directory.

The deployment plan also depends on the client. If the client is not providing machines to their employees, they want the machine to be BYOD, we will work on the existing computer. In that case, we just set up the policies and ask the user to connect to Azure Active Directory. But if a client is concerned about complete security, and they want the machine to be used in a certain way, and they are providing the machine, then I prefer that it should be Autopilot. It becomes an enterprise-managed machine, and we have more control over it.

Microsoft Entra ID's deployment is easy. 

The initial setup of Azure AD was quick and took just a workday or two, although tweaking it took about a week. The implementation of Azure AD probably took about 48 hours. In terms of maintenance, Azure AD doesn't require any maintenance as it is a cloud service that is always up to date.

I would rate the initial setup a ten out of ten.

It was easy.

It only took a few hours to deploy.

It's an out-of-the-box deployment, but I am not the one who manages it.

The process of implementing Azure Active Directory is not straightforward. We are currently still setting it up because we are adding more services, setting up the pipelines, and many other things behind the scenes. It's not as simple, it is tough to implement.

Its initial setup really depends on the customer. I have one customer right now with a super simple environment. They're just replicating it up. It's all Microsoft stack top to bottom with no real surprises or anything else. They're happy as pie with that. 

I have larger customers who tend to want some sort of management layer on top of it for Active Directory management purposes. This tends to go into the cloud, which introduces its own little challenges. In a more sophisticated enterprise, I start running into custom schema or workflow dependencies that just don't translate well from on-prem to cloud, but it is rare. It usually ends up being a third-party solution that we route them to with that. So, it's not huge. The challenge is more in identifying that. Typically, as much as we try, we rarely get it identified early enough to change our statement of work or our implementation, so it becomes a bad surprise.

I wasn't involved in the initial setup, so I cannot comment on that. 

It is not complicated for me as an IT guy, but the feedback from the field or non-IT people is that it could be simpler.

It was a bit complex. We initially had an issue with our IP address, but it was resolved.

The tool's deployment is easy. 

It's quite easy to set up.

The time needed to set up Azure Active Directory is a function of the environment. For simple deployments, it can be done within hours or within a day. But for complex environments, it might take anywhere from two weeks and up. You need to go through an environment assessment and make use of a project delivery framework.

For example, suppose a customer already has on-premises Active Directory services, and the requirement is to deploy or implement a hybrid identity architecture. That means there are workloads on-premises and in the cloud, and the customer wants to use the same identity scheme or single sign-on. Those are the type of requirements that determine how long it will take to get Azure Active Directory set up.

Deployment generally requires a project manager, an engagement manager, and an architect; a minimum of three people. And if there are other specific solution domains that require specialist skills, it could be four.

There is zero maintenance. The focus, in my own experience, is typically around security: how you're monitoring the environment to ensure that it's still secure. And when there are incidents, to what extent, and how quickly, you can triage and pinpoint and remediate to keep the infrastructure secure? But the actual is maintenance is zero.

The initial setup is easy and straightforward. Setting up Azure AD doesn't require you to do anything. You buy the product from Microsoft and Microsoft sets it up for you. You just establish the connectivity to it. It does not take more than a week or two to complete the setup.

The number of employees you require for deployment and maintenance of the solution depends on how you have set up your provisioning platform. If it is automated, you can have one resource. If you're still in manual, then it depends on the volume of the workload.

I didn't set it up, the guys who work for me did it. I think it was fairly complex because we're about to go through an acquisition and we are going to merge them into our tenant. We have to outsource some of that work to a third party to assist us with that because we don't have the in-house skills.

I wouldn't say the initial setup is complex. If you have a good understanding of the product, you can break down your tasks. Then, slowly, step by step you can complete all the tasks.

Our operations team did the migration from on-prem AD to Azure AD. Therefore, I cannot speak to the exact length of time it took. My work was to design the architect and provide them with the solution. 

We found the implementation process to be quite straightforward and simple. It's not overly complex or difficult. 

I installed hybrid Exchange. It was very easy for us. Its installation took a very short time. There was a connector system on Exchange, and we just had to set up the connection. It was very easy.

The initial setup is very easy. You have to enable MFA on the portal for a user, and you have to put the user's phone number. The user can then log in with Azure ID. The user is redirected to the second level of code authenticator and receives an SMS on the mobile. The user needs to enter the OTP.

When you've been dealing with a piece of technology for 25 years, it's simple, but the public perceives it to be complicated and antiquated.

The initial setup of the solution is very easy.  

The initial deployment and setup was pretty straightforward. It is pretty easy. It is not that hard to get going, and the thing is that it is quick to integrate well with your Windows.

The initial setup was very straightforward and simple. It was not overly complex or difficult. We didn't have any problems with the process.

The deployment for the local setup takes some time. For the cloud, it's very straightforward, and it takes no time at all. It takes about two hours to totally install the hybrid, the connection, and go on with the application.

We have about five people who can handle deployment and maintenance duties. That includes me and five engineers.

The installation was simple. I did the flash OS installation, created the role of the Active Directory, and deployed the GPO. The full process of implementation takes approximately one hour and setting the Active Directory domain takes approximately 30 minutes.

The initial setup was complex. It has several forests connected to multiple domains in several countries, and it's going through multiple data centers. Typically, we have a solution for the VPN. It's different in every country sometimes. On top of that, centralized services are not so easy to manage in different forests.

The initial deployment was set initially for six months, and then we’ve been doing improvements for the last six months as well. It’s been a year in total.

Our initial implementation strategy was to sync a forest with multiple domains.

We have ten to 15 people who are capable to handle maintenance on the product. These include a cloud architect to Active Directory architect engineers, help desk engineers to deploy and manage solutions, and engineers to manage the servers.

The initial deployment process takes a couple of days for us, although exactly how long depends upon the type of deployment. If you have new deployments then I suggest creating an automated script that will kick it off because this will save time. If on the other hand, there is something that is already deployed and it needs to be redeployed, it doesn't take longer than a couple of hours.

It only takes one person to deploy. It is done on a ticket basis, as requested by people like our developers.

I didn't handle any aspect of the implementation, as I'm not technical in any way. I wouldn't be able to specify if it was complex or straightforward or how the deployment went.

I have been working in Microsoft Azure for a long time and I find the initial setup to be easy.

The installation was not complex. It was pretty simple and pretty straightforward.

The deployment is pretty fast. It takes ten minutes, at a maximum, to set up.

You only need one person for deployment and maintenance. 

I wasn't a part of the initial setup. I can't speak to how long the deployment took or how easy or difficult the process was.

This is a cloud service, so the initial setup is straightforward. It is not complex.

For each request, it does not take very long.

The initial setup is not too complex. It's pretty straightforward.

It's pretty straightforward depending on what your needs are.

It's easy to set up. 

The amount of time needed to set up Azure Active Directory depends on each customer's use case. It will take at least three to four hours for a small organization, and in that scenario you wouldn't need more than one person to set it up. For larger organizations, it may take a week and we would need two to three persons.

The initial setup was straightforward.

The initial setup is straightforward.

The initial deployment was very straightforward. It only took a day to deploy. The plan was first to get information about our on-premises Active Directory users, computers, and groups, and then we had to determine how many licenses and which types of licenses we needed for those. We also had to think about which type of authentication method we were going to use.

Our deployment involved three to four people.

Maintenance is just checking for updates.

It's easy in its essence, but part of the ease is like anything that seems easy is generally complex when you try and fix it because you've skipped over so many configurations. It's like a wizard that you go, "Yep, it's done." And then it breaks, and you say to yourself, "Oh, hang on, I clicked one button. How could I have done that differently?" It's a lot more stable than it used to be. They've got into a maturity plateau where they're not developing it anymore within for reasons of functionality and the product doesn't really break much.

It is a very straightforward implementation, and you pay as you go. It depends on your number of users, number of applications integrated, and how you prepare your topologies (the arrangements of the network). So, it is pretty much flexible. You can custom tailor it as per your business and target , business implementation and requirement. 

It was a very straightforward initial setup. To be honest, we are a pretty small company so for us it's one portal and everything is there. It's not that complicated.

The installation is rather straightforward.

The initial setup is very straightforward. Microsoft is very good about helping you get things set up, and they're very responsive.

It was not easy. It was also not difficult. It took about a month.

The initial setup is simple. There is not a need to do any installation or configuration, you only make a subscription and you run it.

I found the initial setup process quite straightforward.

In terms of implementation, Microsoft provides very good documentation of how to kick off Azure AD. You just need to follow those instructions and it will be done in a couple of clicks.

The implementation was easy and took approximately three hours.

The solution is connected with Intune in the cloud so implementation is very easy and took me less than five minutes. Everything is updated via Microsoft cloud delivery.

The initial setup is pretty much a straightforward process. I've set up another AD Connect and the process was done in 15 minutes. If you have proper documentation, you can go through it very, very smoothly. That's what my understanding is.

The solution doesn't require any maintenance. 

In general, there is no problem in configuring Azure AD. It's not hard. But, as I said, configuring third-party, open-source applications with it is a little bit difficult.

We usually set aside one day to configure Azure AD for new organizations. In general, it takes one person to maintain it, perhaps two in some cases.

My customers usually do a pilot project. Then it goes to the IT department after that. If they are happy with the features and functionality, then they will deploy it to the users. We typically have no problems, but sometimes we face issues with older devices.

On a scale of 1 to 5, I would rate the difficulty of setup as a 3. It's of medium difficulty.

With setup, sometimes there are difficulties with reading documentation because if you want to implement something, you have to go to Microsoft's instructions, and you will be redirected from one page to another. After reading about just one topic, you have to open 20 new tabs. Every time, you have to jump between instructions, from one instruction to another. I don't like this approach, personally. It should be done in one document, and the instructions could be a little bit simpler for the user.

We implemented Microsoft step-by-step, because first we only used the Office package. Then we started using the Intune solution. Later, we implemented Microsoft Defender, and continued working with Conditional Access. It is not like one setup, so it's a continuous process. It depends on organization scale and the needs from organization.

The initial setup complexity is based on the scenario. If it's infrastructure as a service where you are building VMs, it could take you one day to complete your setup for virtual machines. 

Configuring the domain and setting it up in the Azure portal is just three clicks to be honest. You just need to configure your domain name, you need to configure your subscription to Azure and after that you can just start creating users or different groups that you want users on and depending on your security criteria or how many users. But, the process of actually setting up the tenancy is it's not that hard. I would say it's the work that comes after that requires time and some planning, you know. One must determine how many users you will have and how many domain controllers you need overall. I would say it's not very complicated but it's the planning and fine-tuning that comes afterwards that needs time.

If you have been running an on-premises implementation of Active Directory Domain Services, then it is only a migration. You migrate the identities from on-premises to the cloud. 

If you are setting it up from scratch, it can be easy too. You can do the migration by using Azure AD Connect, which is mostly a straightforward process.

The initial setup is very easy.

The initial setup was straightforward. It has been improving a lot in the past couple of years. Yes, it is a lot easier now than when I first started working with this solution. 

I would estimate that the initial setup would probably take a team a week to set up.

The initial setup was very easy for Azure Active Directory.

The initial setup is straightforward.

Active Directory is straightforward to set up.

The initial setup is straightforward.

The initial setup is fairly complex.

We are a smaller company and it only took us two days to deploy.