Oktane19: Ask the Experts: Deployment Success with Okta Professional Services

Speaker 1: So, Kel Banks, I've been at Okta for about eight or nine months now. Joined the company because it's a fantastic opportunity, love the technology and certainly the space and I've learned a ton since I've been here. Format of this will be that I'm looking for questions from you all to these guys up here, I'll let them introduce themselves in a second. I've got a few questions as well in here if we need a little bit of warming up but feel free to raise your hand and I'll see if I can see you and pick you out of the crowd. You want to start?

Speaker 2: Sure, that's why David asked me to sit here. Okay, so I'm Chris Rengatrom and I'm a senior theoretical doctor. I've been with the company for, this is my sixth year in the company and I started in 2013 and it was so great to see the product, and also I was being in professional services so it's really great to be here and great to talk to you guys.

Speaker 3: Hi I'm Dave Finn, I am a principle architect with Okta. I think this week or next I hit my third year anniversary with Okta. It's been a great time being here, I've been in the industry about 18 years. I work remotely out of the Detroit/Michigan area so I serve Camba, the central customers for Okta.

Speaker 4: Hey. I'm Joesna Raghunathan, senior technical consultant with professional services here at Okta. So I've been with Okta close to three years now, coming up on my third year anniversary soon. It's been a crazy ride so far, the kind of growth that we've seen, the kind of use cases that we tackle. I mean, in every implementation that we go through, there's something unique. So, it's constant learning even for us and yeah, we begin to see patterns across the hundreds of implementations that we do and this is a great opportunity to share what we've observed and what we can do better. So great to be here, thanks.

Speaker 5: Hey guys, my name is Camarujo. I'm a senior architect with the BS team. Been with the company for about just three years now and apart of that I was a customer for two years. So already kind of seeing the situations that are challenges you see as customers and I tackled them as a customer before joining here. I do both types of use cases be they CBDE so happy to addressing any questions that you have. Any challenges that you're looking at. Anything you have in mind based on wh you saw in the keynote, happy to address any questions.

Speaker 1: Cool, thank you guys. And before I forget, thank you all, I mean the common theme aside from titles with these guys just fantastic attitude and clearly the go-to folks. I'm sure some of you who were customers out there that have had some experience with these guys. So, why don't we open in it up? Again, I have some questions if we want to get started, but I'll look out to you guys because it's not about the questions I put together.

Speaker 1: It's more about the question you have so anybody out there who've got questions, fire away.

Speaker 6: Okay, so recently my company merged with another company. We are both Okta customers and we had a challenge around trying to merge our two Okta tenants. And my company's merging into theirs but we haven't been able to get much help, we've tried contacting you guys many times. And basically what we're looking for is we have about 50 different apps on our side that we're trying to move over with the users into the other environment. So I don't know if things are moving in that regard or if there's some new suggestions there?

Speaker 1: Sure, first suggestion is see me afterwards and then we'll make sure that we get to you and move things forward. Somebody want to take a whack at-

Speaker 2: Sure, yes. Let me summarize the question, so you got like two customers. Sorry, you acquired a company and then you both are Okta customers and basically like you are trying to access applications across tenants. Is my understanding correct?

Speaker 6: Right, we can access each other's applications, we can share to each other, but we still have two separate Okta tenancies. We're just trying to shut down one and have everybody from there merge into the other one.

Speaker 2: Sure, this is where I think like Okta is so great because I've seen a lot of customer who come with the mergers and acquisition. It's one of the things that Okta offers is we don't need for example Active directory. Everybody like has Active directory so when you buy a company generally you don't need to actually like go and create a trust or something.

Speaker 2: Often time go and, "Oh, I'm buying a company, I need to build a trust between the active directory and all the stuff." But generally in Okta you don't need to really do that, all you gotta do is just hook up an agent there. Import users into Okta instance. That's where you get things easily.

Speaker 2: And also often time we also see generally like when they come acquisition in your case it's Okta, good, but in some cases it can be a pain. It could be much different stuff. So one of the things I've seen a pattern is it's not gonna be like migration overnight. But at least we can get the users into Okta first which is pretty simple. And then what we want to do is just make sure that we put a plan together to migrate these apps into one tenant.

Speaker 2: That's where I would see like Bazon, whether it's a big bang or approach are, it really depends upon what kind of approach you want to take. At the end of the day, you want to make sure that you provide access in one single view. I want to go to one Okta instance, I want to have access to all these apps. So that's definitely when you say like approach, this is what I would take.

Speaker 2: I would probably first integrate the Active directory into Okta and then bring the users and then basically set up all these things in one Okta instance so that whenever they go something, they always go to this Okta instance that then becomes a habit every day. And then we'll probably start migrating the apps and probably create that federation trust so they can go in one Okta instance and then even they can access the other apps through this. So until you migrate over all the apps.

Speaker 2: It's definitely like a phased approach.

Speaker 5: And is that your desired end state is to have single tenant or do you want to keep them separate.

Speaker 6: Yes, we want to have one tenant.

Speaker 5: Okay, got it. Then that will be a good idea. There is, as Chris mentioned, the only other approach there would be to do a federation between the two tenants so as you are migrating from one to the other you have like a seamless experience with the user. So you can have them coming into one and then access apps and other tenants without having to sign on again.

Speaker 4: So this is from the Okta merging tenants perspective, but think about the apps that employ population from the two organizations they're accessing. So you might have two instances of sales force with unique usernames for each instance. So while you're thinking about merging into one Okta tenant you should also think about consolidating at your service providers your user base. So if I'm from company A and company B most likely my unique username in sales force is due at company A, and then from the other company they're XYZ at company B so how are you going to merge that, how are you going to handle that.

Speaker 4: So that process needs to start early enough because the more number of apps you have the more communication and you need to get all that in place. So that's another thing to be aware.

Speaker 2: Yeah, since you said there's two Okta instance, one thing to keep in mind, you always want to look up what is the licensing model. So basically on each Okta tenant you might have like a different licensing model, so you also need to consider that before you're making a switch. Whether you have all the features enough to even to switch these users into one tenant.

Speaker 3: Any other questions out there?

Speaker 8: Yes, I had a question regarding how you would setup up a test Okta environment. Dev test whatever you want to call. We're starting our journey off with Okta, we haven't actually done a production instance and I was just wondering, is it possible to have that AD sync agent like multiple instances of it pointing from one production AD pointing to different Okta tenants?

Speaker 4: Yeah, I can do that.

Speaker 2: Do you want to just come outside I will just configure it for you.

Speaker 8: What do customers generally do for that acceptance process?

Speaker 5: Usually this is very common between preview and broad environments, you'll have your preview environments, it could be on or multiple and then you have your broad environments. Ideally you should have a test AD you can do a PP environment so you have a full sandbox environment. But we know that's not very common especially if you have large organization where hundreds of thousands of users, you'll only have one production.

Speaker 5: You might have test AD, but it won't be similar to what a production is so customers will opt in to actually integrate their broad AD with all the environments, really from a design standpoint, all you're doing is deploying a separate set of agents for each Okta environment, but that's really all there is to it. Really common though, yeah.

Speaker 2: But one thing to consider is always since you are hooking up your broad instance, you don't want to bring in all the users in your test environment. So obviously you want to create a OU, separate OU or somethings for testing purposes. Because often time when you're bringing for example do work day as a master day, anything like you were trying to do. See, we don't want to overwrite something in the production AD and Okta directory so you need to make sure you were having a separate silo something even in the proud AD's instance.

Speaker 2: And also if you want to test the features of IWA and everything, because you are logging into your computer really like with your product for instance, so it's definitely like an out. You need to consider those things.

Speaker 9: Earlier you mentioned service provider consolidation as something that we need to think about in merger situations. From your experience, what are some tools that do this very well and what are some common pitfalls don't work with an Okta instance?

Speaker 4: So from what I understand you want to know about how we've tackled this in the past?

Speaker 9: Yes.

Speaker 4: So where I've done it, I always advise a phased approach. When you're doing mergers and acquisitions where you have both the companies that are merging are existing Okta tenants. We want to cause as less disruption as possible. So the first as the other panelists suggest would be like a, you know, we set up like Ok to Ok federation and then when we decide to bring over all the users from the two organizations into a one, so we make one Okta tenant as the primary we decide, okay, tenant A is going to be our final tenant and we're going to slowly start merging everything in tenant A.

Speaker 4: So assume one stage you've brought all users over to tenant A. So you have two sales force applications, you have user at A dot com and user dot B dot com. So what we've done is we've done using Okta universal directory, we've done transformations where temporarily, even though your username has changed, you've come to the A domain, we can still transform your username to be at B dot com so to that service provider we keep that same unique username and once we start consolidating at the service provider at a certain cut-off, we'd remove that transformation.

Speaker 4: So it has to be staged. You cannot do it all at once. That's been my experience.

Speaker 1: Anyone want to add?

Speaker 10: Hey, I'm curious about your acquisition and scalibility in the advanced server access tool and you've just announced I think at the show access gateway and I'm curious how professional services support some of those advanced featured. How you get trained if I'm starting to work on something like that, do I want to ask for a particular person who knows what they're doing.

Speaker 10: And what are any considerations about ruling out that technology?

Speaker 3: So yeah, so we have announced the advanced server access product. It is available today in general availability and same as everybody else, PS is doing our on onboarding of our expertise with that and we are ready to assist with that today for you.

Speaker 3: So the best thing to do would be to reach out to your engagement manager and see how you can best engage with PS for that specific to the access gateway. That's still an up and coming product that I think is announced to be coming sometime this year so it's probably not something that we can obviously help you go setup today until it's at least in beta mode.

Speaker 5: I just want to add there, as these are brand new products, the training is still not available yet. As soon as it's available, well as we can build out these new product capabilities, PS is usually the first one to work with customers as they are trying this out and as part as they're building it out. So once it is available, at least we have some team members who are ready and able to assist customers who are the first ones to go live with these features.

Speaker 2: So one the things I would suggest for everyone, I want you guys to look up our beta programs. So whenever there's a beta program it's really good time for you guys to go and sign up for this beta. Because we are providing a nice documentation also regular like the way you can setup. It's not just a documentation, we also provide some involvement in some cases where you can just go and test those everything.

Speaker 2: So generally and definitely you guys need to take a look at the beta program and you want to talk to your customer assistance managers or engagement managers and say hey, how can I get signed up for this beta. So that's definitely one of the things considering all these features before it comes to like EA or RGA.

Speaker 11: Can I follow up? So okay I see in the article you were saying you were just announcing it and later this year the access gateway will be GA so it's just beta. Bummer. The advanced server access, I think maybe you guys have it beta to Linux environments right now is that true or is that on Linux of RDP?

Speaker 4: It's Lunix and RDP.

Speaker 11: Both supported in GA?

Speaker 4: Yes, both are supported today. So Scality already had existing customers like Rackspace and others. We have some beta customers who are onboarding and it is life for a lot of the existing Scality customers, Okta customers have started onboarding so we do support both Linux and SSH. They are using it in production so that's where we are with advanced server access.

Speaker 11: Okay, so advanced server access for Linux and RDP is supported GA right now?

Speaker 4: Yes.

Speaker 11: Okay, thank you, so when I got there, I'll be able to do that, but access gateway is still down the road and beta programs are not even active right now or they are?

Speaker 4: Firaxis gateway, I have to check on the beta program, I am not aware at this point.

Speaker 11: Can you guys talk about what the beta program needs? I mean if I get signed up for the beta program can I roll it out and you'll support us?

Speaker 4: Yes, so I think the way we work, if you have a CSM and you go to the beta site, there's some beta programs that you're interested in. You contact your CSM and they kind of fascilitate with the product.

Speaker 11: I tell you we're using Duo right now, we'd like to just replace the whole thing, but they have the Duo network gateway which is a reverse proxy tool that supports not having to have VPN tools to get into applications, which is essentially what this access gateway tool is gonna do. If you guys had that, we could go full blown on there, but if you have a beta program for it, you're saying I can potentially sign up for that and if I get approved, we could start moving into that architecture.

Speaker 3: Yeah, the beta programs there's a large number of them that are available online for you to go try and self enroll in otherwise you can as Joe mentioned, if you have customer success manager, try and work through them to get enrolled or talk with someone after this meeting.

Speaker 3: I'm not sure of the status of the access gate. We'd be at this point, but to Chris's point here, I equally encourage everyone to participate in the beta programs because that gives you direct access to the product managers who are building out that product and they will talk to you. They'll kick off your experience with the beta manager and they will survey you allowing the way. And if you want to be able to influence the future of the product, that is the best time to do it because it's going to change during beta, but once it's in EA, the likelihood of change is later.

Speaker 3: Specific to the advanced server access. It is fully supported, it's now fully integrated with Okta as well and that was a large part of the announcement that was going on today. It's not only there, are you able to buy it directly through Okta itself, but it has direct integration so that you can create your users in Okta and have them automated provision through the gateway into your Linux and Windows servers.

Speaker 2: So one thing to add to it, when you said like a rollout, just to be careful because beta programs are just beta. So it's not pretty for rollout to production and also it's not supported by support so you can't really make a support tech error or something saying like this better program's not working or something. So it's totally like the beta programs are always through beta programs and then you have a proper channel to communicate your feed back and everything.

Speaker 6: Hi, again, sorry. We have Azure AD connects in place today. Again, we're new Okta customers, using Azure AD connect. Have you seen the customers that are existing Office 365 environments using Azure AD to connect, are they transitioning to use Okta as their provisioning tool? And how often does that happen, I'm just wondering.

Speaker 2: Sure, in Okta today we support on like cloud only provisioning so basically which means you should be fully cloud in Office 365. We don't support any hardware provisioning today. It's because we don't write back any data from Office 365. So if you are fully cloud, sure, you can definitely take advantage of that.

Speaker 2: Because one of the capabilities, I mean, it's really good, easy and also I've seen customers where they brought in terms of mergers and acquisition where they are trying to bring in from multiple actor directory instance. And they can do an easy transformation in Okta and they can just get that one right into your head basically like synced into.

Speaker 2: So definitely I would recommend if you are fully cloud, yes.

Speaker 6: Thanks and one more question. Certification tests, apparently they have a bit of a reputation for being difficult. I assume you're all certified, how do you guys go about preparing for this?

Speaker 2: I wrote some of the questions.

Speaker 6: Can you give me the answers.

Speaker 3: Yeah, Chris cheated because he wrote the questions so he gets himself excused from taking the exams. No, they are definitely challenging I think for us, we're probably the worst people to ask and prep because if you live using Okta, we kind of bleed it day in, day out. And so that's how we prepare is working with everyone in the room here to actually implement the Okta.

Speaker 3: I went through and take the sample test just to make sure I wasn't gonna be completely off the charts as far as being wrong about able to get to it. They are tricky and the format is tricky that's dead for me and that's why encourage everyone to take the sample test if you're gonna do certified. Be prepared for the format of the test I think that's the hardest thing.

Speaker 3: Everyone's used to multi-choice from multiple-multiple. And if anything threw me off it was understanding the format of the test itself.

Speaker 12: He stole half of my question with the connect replacement. Since we have a hybrid should we be looking at decomming our on prim presence since 98% of stuff is in the cloud and we could move everything else up there and is that what other companies are doing or do they just stay perpetually in the hybrid environment and yeah.

Speaker 3: I'll start. At least from my experience, the ultimate goal for every company I work with is to be fully cloud and to not have hybrid. Usually it's more of a pain point for them is to the only reason that it exists in hybrid is being able to move certain groups of people. And if they can move them quicker, they would, but that is definitely their endgame is to shut down the hybrid, shut down the AD connect.

Speaker 3: Get rid of the ADFS if at all possible, those are all huge wins for whom we work with.

Speaker 1: I thought that would be a very provocative question from this crew.

Speaker 13: Hi, going back full circle to the first question that was asked about merging Okta tenants, we are kind of in the same boat. Just went through a merger and my big challenge what I'm seeing is, do you guys have a tool to migrate a same old app from one tenant to the next tenant or do you just have to recreate it all over again. Work with the vendors. That's the biggest challenge that I see. We already have org to org set up so that we can share apps between both companies, but we really want to have that one Okta tenant and share it between both companies, so.

Speaker 4: I can take that for him. So we don't have anything productized in terms of something that product supports to take the configuration and slap it into another tenant. But in PS we've developed some postman's trips and things like that that can read our absent point, parse out all the configuration and then it can post it into whatever new tenant you want to send that to.

Speaker 4: So if you would like access to that, I can share that with you.

Speaker 3: I think to Joe's point, the biggest thing to recognize is all of that app configuration, at least virtually all of it is available through APIN points and so it's a programmable effort if you're willing to take the time to do it.

Speaker 14: And that particular tool that you talked about to be able to potentially move from one tenant to another, I can see where that would actually be very useful in a highly controlled environment as well. Because you can actually then have a continuous deployment to production without having to somebody rekey it. Is that something that's in consideration to move out of your hands of a strategic tool into more of a product or a offering?

Speaker 4: So that's been a long ask for all our customers. Even when you think about moving from preview to production, you do all your testing and preview, you are ready to go to prod, you have 50 apps, you don't want to configure everything manually. You would ideally like to just push everything and then make whatever, like swap out the URLS or things like that.

Speaker 4: But as of today, we don't have, like I said, any productized tool to do that. And we've encouraged like when they do configuration porting from preview to production, you normally have one preview window open and one production. And we would like users to be very cognizant of the changes they are making because it is different. Your endpoints are different, things like that are different. So I can see where productized thing would be helpful to get that initial base and then you go and make the changes.

Speaker 4: We can certainly take the feedback back to product, but as of today we don't have anything. It's mostly we use APIN points to extract and stop back.

Speaker 3: Yeah, and to Joe's point, it's definitely been a frequently asked question. Everytime I kick off a customer meeting, they ask how do we automate pushing from preview to production. So, I don't necessarily think it's on the short term roadmap, but I definitely know the product team is well aware of the demand out there for that.

Speaker 3: Would I try talking to most customers about is potentially thinking about Okta the same way you think about a sequel database and how do you make changes to the database. You don't go into the database and just starting altering cable, creating tables, you write scripts and then you react to those scripts in each environment. Since those are all APIN points that you could be doing with Okta, you can treat Okta in the exact same way.

Speaker 3: Porting that data because, to Joe's point, is gonna have different configurations, the URLs to your apps and production are gonna be different than they are in staging. The certificates that you're using are different between preview and production. There's not gonna be a magic, but you can potentially isolate that config and more streamline it through continuous integration processes. Totally agree.

Speaker 15: Hey, we're ready to go live with Okta and we're on prim big AD historical user and we have single farce multiple domain and we have region OUs for all of our users. Do you find that okay, so sorry we're shifting to HR as a master Okta provisioning down to active directory. Do you find most people in that situation actually mapping OUs into Okta tenant or do they just flatten the AD structure as part of that great one Okta user OU into all the management from Okta. How do people typically map factory directory to Okta in an Okta master scenario?

Speaker 4: So are you talking about HR to Okta down to AD?

Speaker 15: Correct.

Speaker 4: Okay, so my experience has been it really depends on ... so you know that based on OUs you can push users coming in from HR into Okta based on some attributes, say location or department. You can put them in different Okta groups and you can configure those groups to write down to AD to specific OUs. So what I've seen is clients are very excited about that and they want to have several OUs and then they want to you know, but something the ADT wants to have control over that.

Speaker 4: So a lot of times they've gone with, okay, we're gonna push it into 50 different OUs, but then as they come closer to go live, they're like no. We want more control over this. And everybody goes into a single OU and the ADT manages it from there, so that's been my experience, I don't know about you guys.

Speaker 2: I think one of the key considerations you need to think about is how much of processing you want to make in the cloud versus on prem. Key thing whenever I go to an architecture workshop or something, customer ask like okay I have today this process, can you do the same thing in Okta. So that's first of all, that's what change. So old process are old processes, so you need to first of all modernize those processes. If you have 50 OUs, definitely don't go with 50 OUs, just think whatever is necessary.

Speaker 2: Maybe in the olden days it was created for a reason, do you really require that right now, I don't know. So that's the question I would ask. So I want to make everything simple and that's why Okta makes your life simple. So obviously we just want you also adopt the change. So change your OU structure, make it like pretty minimal so that we can do more automation in Okta side.

Speaker 2: So that Okta can give you that full feature set.

Speaker 15: Alright, thank you. And just to expand we have 300 OUs currently. One of the problems is we're migrating to HR to Okta to AD, but we have 30,000 existing users in AD and they don't all align with the information that's in HR. So, porting those existing users up into Okta has proven quite cumbersome for us. Thank you.

Speaker 2: Definitely you need to think we are getting a lot of new features like in-line hooks and everything. You guys also need to consider those things. When you architect a solution, think always like for example like group rules. People would start writing like dynamic rules in Okta, good, but if you're going to have like thousands group rules, is it scalable, I don't know so that's really a question you need to ask.

Speaker 2: So whether I want to process this many rules, I want to process in the cloud, those kind of things.

Speaker 15: Thank you.

Speaker 16: Hi there, we're actually a new Okta customer and we're just getting ready to do our deployment now. We have probably the complete opposite to the preview's use case where we are a 100% remote, 100% cloud company. So we have an entirely remote workforce. We have very heavy users with cloud applications. I think in our application identification, we're easily over a 100 applications in various spaces.

Speaker 16: I guess the question I wanted to ask you was from your experience one of the biggest challenges that we're identifying is having a remote workforce getting that user adoption of Okta taking them away from their previous habits. I won't call them bad habits, I'll just call them habits.

Speaker 16: And also noting just as general question. Are there any particular cloud applications that are risk or danger factors that need to be considered when doing that sort of application migration from static or using Google or type things to moving it towards Okta.

Speaker 5: So what are you really looking for in that scenario. Are you just looking at it from a user experience standpoint. That users are migrating or you're used to using let's say going directly to their service provider and now they're coming in through the okay dashboard. Like that user experience changed or is something different?

Speaker 17: Okay, we are currently using Google Auth. We also have the One-Password. So we are kind of trying to as he said, renew customers. To be trying to try to close down on everything and go through Okta. To make it simple for the people ops guys to kind of manage the remote workforce.

Speaker 17: So we just want to know how can we do it better. What would be the first phase that you'd start off with.

Speaker 5: Yeah, that's a great question. It's actually very common. We do suite in all our engagements as customers who are migrating to Okta. There is always going to be that education and training component to this. So we do have a toolkit that we publish. It's on our support site that you can leverage. It has the Okta onboarding elements to it. So emails that you can send out, bolsters, presentations we can do, demos.

Speaker 5: You want to share that with your user base early on and say here's something that's being introduced. Here is how your workflow changes from today to Okta and if you're MFA and such, here's how you enroll for it. If you can, use it in such and such factor here, some fallback options. So once you have that and the idea then we really built out this toolkit and this collateral based on the feedback we get from customers.

Speaker 5: So Auth customers used that and they will repurpose it's availability in a raw format so you can change things around, but you're banning in there, but highly recommended. If that can ease your role into our journey over to Okta. If you're seeing that be a problem, what he can do is roll out Okta on a per app basis. You end up releasing the small populations, learn from the challenge there, looking at and then just tweak or messaging so it's a little bit smoother moving forward.

Speaker 3: Yeah, so just to add onto that, the communication is key. The sooner, the earlier, the often, the more frequent, this is coming, this is coming, your life's about to change for the better. And so I encourage that all the time whenever I kick off a workshop, get those key people who are responsible for communications involved, engaged and participating in the meetings with us. So we can better even that process.

Speaker 3: And then also think about that from the experience standpoint as you're planning your role out. As Cam was mentioning, I'd be thinking about trying to start with your high value apps. The ones that they use the most and potentially the ones that you are most are looking to secure in a better practice. Your opening there about being remote workers, that's our life. We're remote workers, we are never in the, well rarely in the office I should say I was in there yesterday.

Speaker 3: And we use Okta of course ourselves so it can be an awesome experience from that standpoint. And similar to Okta has no active directory. When I talk to the customers about this they look at me like wow, that's an option? But when Todd's up there saying we were born in a cloud he means it and we live it, so.

Speaker 4: I have another comment to add. A lot of my customers, communications is key, right? They get their communication team onboard, like once we have tested everything in preview, they're so particular that they screenshot everything, what's gonna be the user experience. Say, you're cutting over Office 365, single sign on changes from ADFS to Okta in a desktop app, this is what it's gonna look like.

Speaker 4: Get those screenshots and give that message to your users as early as you can so that's a good takeaway there.

Speaker 17: Okay, let's pull that communication theme. Say it's a month before you go live and you're meeting with the CEO, CFO, CIO and so so. Based on all your experience, what would you say to them for a definition of success. And then number two, Chris I love the bowtie.

Speaker 2: I thought like actually I don't even know they would put that photo. And then like I thought they would pick up me from Slack of something, but they pick me up somewhere else. Okay, so do you want to take the question?

Speaker 4: If I understood correctly, you said how would you define success to the leadership. Was that your question?

Speaker 17: Yeah, potentially being a month out.

Speaker 3: So I will say success varies by miles and it's a little bit tricky for me to answer because it depends on the project. With that little bit more information, if this is trying to roll out workforce sort of customer identity, a lot of times from our standpoint how you define success is really how we engage with you. It's the first think I want to understand, what are the goals and objectives you're trying to achieve so if you're bringing out workforce identity.

Speaker 3: If you're trying to tighten up security or trying to give it a bad practices, you're trying to get rid of help desk, calls, reducing friction. Increasing positivity and experience and things like that. Those are the types of things that I'd be looking for specifically and if I were having conversations with your sea level associates, that's the kind of level of discussion I'd be having of those types of usage of Okta and what it's gonna bring to you. Is it a cost savings because you're gonna get rid of site minder, help desk reduction cost, increase security, unique compliance requirements, things like that.

Speaker 5: Yeah, probably it always goes back to the compelling factor for why you brought Okta in the first place. So, yeah, exactly what they said. If it's security driven, it'll be something you Cisco will drive. If it's user experience driven, probably it's coming from your IT or your marketing teams.

Speaker 5: And then you want to trace that back so if it's password research is taking a lot of time and support desk is always bus with those and there's a cost associated with it, we're gonna bring that down. Your success metrics are how are we gonna do our password recess with Okta and placing that and saying my goal is to have 50% of my user population to use theirs over the next three months, next year and then just tracking that.

Speaker 2: Yeah, so one of the things that I would always say to CEOs is so you need to think about a longer term. So basically how you're gonna do this. It's not gonna happen over the night, obviously people think I got Okta today, I want to just save money. So I want to completely migrate off probably like rip-off AD. So I'm just saying you really think about what is that milestone.

Speaker 2: Because always the CEO or CIO is looking for that roadmap like long looking roadmap. What is that in three years, what I want to be, what is Okta gonna do for us. So where we can replace things with Okta and how Okta can help. So that's probably the roadmap as one of the key things to even success.

Speaker 1: It's rare that I ever get to speak on these things, but I would say one of the biggest lessons that I've ever learned as a PM was, let me back that up first. I'd say you'd look what was the rational for budget allocation initially and the success criteria is hidden in there somewhere. The most embarrassing question I was ever asked was when we were celebrating a successful implementation was, I know I'm different. Am I any better? And I couldn't answer that question.

Speaker 1: And it leads back to your question. I didn't know what the success criteria I was too young as a PM, but I would hang the hat on the program or the project manager to go back to budget allocation and look why it was funded, why the purchase was funded in the first place. In there lies the success criteria and then all the way through your roadmap that changes as you get more and more educated.

Speaker 5: This is probably applicable to all Okta deployments, but where BS is engaged for larger customers, we do have BBA team that would do an analysis of why they are bringing Okta in and that gets communicated to everyone who is working on the project. BS, CSMs. So we do track it to say yeah, that's the customer's goal, this is why they're bringing the Okta in here is to main points. Let's make sure we address them and then once BS deploys and customer's live, your CSM will track that and follow up with you and make sure you're getting traction.

Speaker 18: I'm just wondering if there's a good way to get on prem's agent serving multiple tenants or a good way to get multiple on premis agents running on the same server. Each serving different tenant.

Speaker 2: So when you say like on-premise agents, like on-premise provisioning agent.

Speaker 18: Yeah, on-premise provisioning agent.

Speaker 2: So on-premise provisioning agents like yeah so pertinent. Obviously we want to deploy multiple things because it's gonna take a lot of loads so basically like when you ... and also like Okta natively tests the load for that. So all you gotta do is just install the late agents and a couple of license. And hook up into one Okta tenant.

Speaker 18: But is there a way to get it to serve multiple Okta tenants?

Speaker 2: Yes. Oh, the same agent.

Speaker 18: The same agent serving a number of tenants.

Speaker 2: No, because I think when we install agent, we're specifically saying I want to connect this agent to this Okta instance.

Speaker 18: And that's what we've been doing and we've been hacking the registry to move stuff out of the way before installing another agent to run on the same host serving a different tenant. But it seems very hackish so I'm just wondering if there's a better more wholesome way to do it.

Speaker 2: I don't know if it's hackish or something because it does right now when we started the on-prem provisioning agent journey, like we did not even have SSL support to it, so we just had like probably on prem provisioning agent. Today we in-build like SSL support to it, so you need to basically like how secure socket layer even to install an agent.

Speaker 2: So it's all just things, it's probably like good thing right?

Speaker 18: Yup.

Speaker 2: And obviously we are PS, we always want to hack something out.

Speaker 1: On that note, we're running out of time. We're running out of time, it's up to you guys, you want to have one more question before we break, ailing, burning?

Speaker 2: I have not hear any questions on Amife or customer identity. That's what I have Dave hear for.

Speaker 1: Alight, well thanks you guys, I appreciate you taking all the time. I love that I didn't have to do much here.