51ºÚÁϲ»´òìÈ

Transcript

I guess you have to share the slides again, Marco. Okay. Good morning. I see a couple people coming in. We’ll give it just a minute to allow people time to join.

Yes, the meeting will be recorded. You’ll have a link available at the end of it. And I think on that note, maybe I’ll just get started with the introduction and people can review the recording if they come in a couple minutes late. So, yeah, good morning, all. Welcome to the 51ºÚÁϲ»´òìÈ Ultimate Success webinar on migrating from service account JWT to OAuth server-to-server credentials. Marco, next slide, please. Okay, we’ll start with introductions. My name is Jeff Holmquist. I am a senior field engineer with 51ºÚÁϲ»´òìÈ Ultimate Success. I joined 51ºÚÁϲ»´òìÈ in 2021, specialized in AEM. I’ve been implementing AEM since about 2015. Also with me, who will be presenting today is Marco. Marco, if you want to give a couple sentence introduction. Yeah, absolutely. My name is Marco Lara, and I’m also a senior field engineer with Ultimate Success. I’ve been with 51ºÚÁϲ»´òìÈ for about three and a half years and I’ve been working with AEM since 2015. Very similar to Jeff. As a matter of fact, Jeff and I actually started almost at the same time. So that’s about it. Okay, thanks, Marco. We’ll jump into an overview of the agenda. So we’ll first be talking about JWT and OAuth, what that is. We’ll be talking a little bit about why 51ºÚÁϲ»´òìÈ is deprecating JWT in some scenarios. We’ll also be talking about some special AEM cloud and 6.5 considerations. After that, we will have a step by step migration guide, including a demo portion. We will also be taking Q&A throughout the meeting and get to any unanswered questions we can at the end. So a quick note on that, if you have any questions you want to ask, we have both a chat and a Q&A pane. So please use the Q&A feature of Teams and we’ll take as many of those questions as we can. So today’s targeted audience is mainly aimed at application developers, technical leads, integration architects. Anybody who’s currently using JWT credentials in 51ºÚÁϲ»´òìÈ applications, with the big point being that those must be migrated by the end of January 2025. So as we get started, we have a quick poll just to gauge people’s current knowledge of this JWT migration. So I will go ahead and launch that poll. And I think in the meantime, Marco is going to start getting his slides ready. I don’t know if you want to just wait one minute, Marco. Yeah, we’ll go ahead and wait one more minute just to people to give a chance to react on that poll. And I’m sure you all see it, but the question is, have you identified the applications in your organization that currently use JWT? All right. With that, let’s go ahead and start diving into the content. So good morning, afternoon, evening for those that are listening in. Before we dive into the migration and details on the demo, I’d like to kind of give you some background on the two authorization methods used for 51ºÚÁϲ»´òìÈ services. So we have JWT or service accounts, as well as OAuth2 credentials. I’m not going to dive too much into the technical aspects of these two integration patterns or authorization patterns. There’s plenty of documentation online. These are just, these are not specific to 51ºÚÁϲ»´òìÈ’s technologies. I mean, these are very well-known technologies that are out there. I’ll be providing enough information on how they are used within our 51ºÚÁϲ»´òìÈ services and integration capabilities. So the first thing I want to talk about is the service accounts. The JWT2 is a specific type of credential, also known as the service account or JWT2 credentials. You can actually hear both of them in documentations and as you’re reading through some of the migration documentation. And generally, a service account is used as a standard for secure data transmission. But 51ºÚÁϲ»´òìÈ has adopted this for authorization in many of its services and APIs, and particularly in the 51ºÚÁϲ»´òìÈ IO developer console. And now the important point here is that, and the reason that we’re actually having this webinar is that 51ºÚÁϲ»´òìÈ has announced that this type of authorization method would no longer work for some integrations after January 25th or 27 of 2025. So now it’s critical for all customers to plan the transition to OAuth as soon as possible. Now, OAuth brings us a different approach to authorizations of services in 51ºÚÁϲ»´òìÈ. This server to server authentication is known as a two-leg authorization. Unlike the three-leg OAuth methods that are out there commonly used, which involves three parties, a two-leg authorization only requires two, which is the 51ºÚÁϲ»´òìÈ IMS and the client’s applications or the 51ºÚÁϲ»´òìÈ services needed to be authorized. So this is kind of how it works. The application uses its own credentials like the client ID and the client secret to authorize itself and generate an access token. Then there the access token is once it’s generated, the application can use it to basically authorize itself on the APIs on its behalf. Let’s go ahead and move on. Now let’s dive a little bit into why 51ºÚÁϲ»´òìÈ is duplicating the service account. 51ºÚÁϲ»´òìÈ strongly advises migrating to OAuth server to server before the deadline to benefit from the advantages and ensure content, continuing access to the 51ºÚÁϲ»´òìÈ services. Let’s go ahead and analyze a little bit of the timeline. 51ºÚÁϲ»´òìÈ has been working on providing services to our customers to prepare and to migrate all service accounts to the new OAuth credentials. So back in May 1st of 2023, 51ºÚÁϲ»´òìÈ announced the future deprecation of the service accounts. From May 1st, 2023 to June 2nd of 2024, customers can still create the service accounts, but migration to OAuth is strongly recommended. On June 3rd of 2024, the new service accounts credentials can no longer be created and the existing JWT credentials or the service accounts will continue to function. Around the same time, customers were able to create both OAuth authorization credentials and JW, I’m sorry, they were able to create the OAuth authorization credentials in the developer console. For cloud services customers, this is for AEM, there was a minimum release version of 17.25.8, but right now the current version is 18.75, so it’s been out for a while. And for 65 customers, a minimum release version that allows them to create or to configure the OAuth credentials is service pack 18. So on January 27th of 2025, service accounts reached the end of life and all the APIs using the service accounts will cease to function and all your applications and integrations will be experiencing authorization failures. So here are the benefits of actually moving on to the OAuth 2.0 credentials. It’s just simplified development. It leverages existing OAuth 2.0 libraries for easy integration. It enhances the security, no need to manage and rotate expiring certificates anymore. And it’s just a streamlined maintenance. The client secret rotation can be done through the UI in the developer console or through an API. All right. Now, let’s talk about a little bit about AEM. And the reason why this slide is in here is because we get lots of questions from customers that have AEM implementations and their biggest question is how those implementations are going to be impacted by this migration. Well, one of the biggest questions is the scope of the migration, whether this is going to affect for cloud customers, on-prem customers, AMS customers. Another question that we get is how is this deprecation of the service accounts going to affect their access to the AEM instances? And just to kind of make some clarification to some of those questions is there are three main authorization patterns that your team should consider when evaluating how this migration will affect you and the AM implementations that you’re working with. The first one is the 51ºÚÁϲ»´òìÈ IMS configurations. These AEM implementations are using the cloud or legacy cloud services configurations in their AM environments. These integrations are using the 51ºÚÁϲ»´òìÈ IMS configurations that are configured to use the service accounts. Some examples of these are 51ºÚÁϲ»´òìÈ Target, Analytics, 51ºÚÁϲ»´òìÈ Launch. These types of integrations are impacted and will require the migration before the deadline. This applies to all the customers for on-prem, AMS, and cloud services. The second pattern is the 51ºÚÁϲ»´òìÈ as a cloud service, cloud managers, AEM developer console. This is the authorization and access to the resources in AEM instances in the cloud. For those familiar to AEM as a cloud service, this service accounts is accessible through the integrations tab in the AEM developer console through cloud manager. There is no impact to this specific service. Customers can still create the service accounts and local tokens created in cloud manager that supports the JWT credentials and have access to their AM environments through that token. Engineering is currently planning on modernizing this service, but there’s no timeline of that just yet. And the last, this is not really kind of involves the migration, but this is a specific pattern for 6.5 customers. This is the AEM OAuth scopes. Basically, this is an integration that allows you to configure an OAuth client in 6.5 implementations and use that pattern to access resources within AEM. Again, this is not impacted, but I just wanted to include it here just to give some context because you will be also hearing some questions about this is going to be impacted some of the OAuth scope and implementations for 6.5 customers. All right. And with that, we’ll go ahead and before we start diving into the demo, I would like to have another poll.

We’ll give people just a minute to take a look at this question.

Looks like we’ve got some answers coming in, so. All right, great. So let me go ahead and switch over to my desktop real quick. OK, great. One thing that I want to call out is that any projects that are MARC auto-generated are not impacted. I will dive a little bit into that, but part of the preparation to figure it out, whether or not you need to migrate some of your credentials or the service accounts is if you log into the 51ºÚÁϲ»´òìÈ Developer Console and go to the project section. Or the tab at the very top. You will have these filters to the left. 51ºÚÁϲ»´òìÈ has made it kind of easy to identify the ones that you need to migrate or that need attention. There’s a little checkbox that says has service accounts JWT. And this will give you pretty much the list of all the projects within the console that will require to have a very deep review on whether or not these need to be migrated. Now, the reason that I say whether or not is that there’s an opportunity for your team to kind of look at every single one of these projects and evaluate whether they need to be migrated or they just need to be deleted. You know, there’s some sometimes you have projects that are test or you’re no longer using for POCs. And this is a time when you can actually start with a clean slate and just delete any of those projects that you’re not using. So what you want to do is you want to log into or open up any of those projects and look at the… It’s going to take a little while. Look at the time that it was created, look at the time that was last modified and who it was modified by, and then just go and talk to that person and figure it out whether this is something that needs attention. If it’s a project that has integrations that are not being used or there for testing purposes, but you do still have some service accounts, you make the decision whether or not you need to migrate this project or you need to just go ahead and delete it. Right. Going back to my list. I do have one that I’ve been preparing for this demo. All right. So this one. So as you can see. On this project, I have some integrations that are used in the service accounts. So I have Cloud Manager, I have Photoshop, I have Target. Let’s go ahead and take a look at any of these. So if I open up some of these API integrations, I will see that this specific API integration is using the service accounts. Right. And what I want to do is once I determine that this is an account or this is a project that I need to migrate, the very first thing that I want to do is I want to click on the service credential. All right. And the developer console for that specific project is going to provide you with this little screen or widget that will facilitate the migration of service accounts to OAuth. So let’s go ahead and start a new credential. And this is just giving you confirmation and you want to continue. Yes. Which, by the way, by initiating a migration that will not affect any of your integrations. Once you start this migration, then all of your integrations or your APIs will be able to access both of these credentials. All right. So if we go back to the project overview. You will see that this project now has both the service account and the OAuth server to server credentials. If I open up any of my APIs that I’m currently using. You will also see that the credentials are for service accounts and OAuth as well. So what does that mean? It means that this specific API is using both of them. So now what we want to do is we want to start. Migrating. The credentials from service accounts to to to OAuth. And the way to do that is by let’s take a look at this. I’m going to be using two APIs just to kind of showcase the migration. So the very first one I’m going to do is I’m going to do 51ºÚÁϲ»´òìÈ Target. This is an integration that I’m using with my AEM environment. So if I go into my AEM environment. If I go to my cloud services legacy configurations.

I’m going to target.

OK, this one is using my JWT 51ºÚÁϲ»´òìÈ Target IMS configuration. Well, I want to migrate this over because it’s going to stop working in late January next year. So the way to do that is. I’ll go ahead and to my. 51ºÚÁϲ»´òìÈ IMS configurations. Again, if you are on service pack service pack 18 or above, you will get this error at this message that says that this credential is deprecated, then you need to you need to update it. So the way to do that is you create a new integration. You select the 51ºÚÁϲ»´òìÈ Target. This one is going to be.

And the authorization server, I’m going to get it directly from my server to server.

Right. OK.

So the authorization server, actually, I’m going to reuse this one. They’re actually the same. So.

Go ahead and create it again. Right, client ID. Copy it from my project. Whoops. Client secret. Also. Copy it from. Console. Scope, since this is specific to Target, what I want to do is view all my scopes that I have. Right, so I’m going to go ahead and copy. My scopes here. And I’m going to go back to my credentials and I’m going to copy lastly the. Let’s see. Last one is my org ID. All right, so my org ID, I’m going to refresh.

The org ID is the same. As the JWT, so I’ll just go ahead and copy that. All right. So now my AEM instances has these two configurations for Target. If I click on this one and I check the health of it, this one’s going to say that it’s healthy, that it’s connecting correctly. If I select this one as well. Check the health. This one’s going to say that it’s working as expected. All right, so now that I have this migrated, let’s go back to the. The project overview. OK, so I have 51ºÚÁϲ»´òìÈ Target already migrated. As a matter of fact, if I go into the migration step.

Right. What you want to do is you want to migrate all of these other services that you already have. All these other services, I’m going to go ahead and do another one for Cloud Manager. So what I’ll do, I have one here that an API that I’m using for Cloud Manager, this is using the service account. So I’m going to go ahead and click on send. As a matter of fact, you will see that I get a response. So what I want to do is I’m just going to copy this.

I’m going to go ahead and create a duplicate of this. I’m going to go ahead and rename this to off. Right, I’m going to go ahead and edit the project.

Variables.

Change the variables. All right. So now what I’m going to do is I’m going to use the server to server credentials.

OK.

So one thing to note is that. The API key, the org ID, the technical account ID, the client ID and the client secret. But all pretty much. The same.

The only the only thing that changes really is the access token. So let’s go ahead and generate one.

Then copy it. And modify this.

I’m going to add scopes.

I’m going to go back to these scopes and this is for Cloud Manager. Here we go. Copy those.

Right. Save. And let’s go back to my calls, my APIs. So if I. There it is. So now this API on Postman has been already upgraded. So at this point, I’m good with Cloud Manager. Let’s go back to this. All right. Let’s go take a look at the overview of the project.

So you have to do that to all of the APIs and services that you’re using if you actually open up. Any of them, and you need to know more about how to do that integration. Every single one of these APIs do come with a documentation of usage and. And it kind of how to how to use those credentials, for instance, this one’s is for Firefly, I believe. So this will tell you how to integrate with with the new credentials. So you just have to go over each one of them and actually do the migration. You do have the option to cancel a migration. So let’s just assume that you don’t want to continue with this migration. You can cancel this migration. And what that’s going to do is going to remove your OAuth server to server. However, if you have already some integrations that are using the OAuth credential, like, for instance, this one or AEM, then basically you’re going to get authorization issues. One thing that I forgot to do on AEM is go into. You need to go into the. Legacy. And then edit this one is using my JWT. Now we’re going to change into OAuth and test, reconnect, reconnect. It’s working fine. There you go. So, for instance, if I cancel the integration, the migration, I’m sorry, then this specific integration is going to give me some failures because that credential is no longer available. Now you have to go and do that migration for all the APIs that you’re using. And once that’s done, then what you want to do is you want to review. And this is going to tell you when it was the last time that that OAuth server to server authentication happened and when the service account last access token was generated. You have to evaluate when it’s safe to actually delete this credentials. We don’t recommend to actually do it right away, since both of these credentials are actually working and the service accounts will stop working in January. What we recommend is give yourself a week or so before and make sure that all your integrations are working with the OAuth, with the server to server credentials. And once you determine that everything’s working fine, that when you do is you come here and then just confirm and continue. And what this is going to do is it’s going to delete your all credentials.

Let me just give it a minute. In the meantime, Marco, I did have a question in the chat and you may have touched on it, but anything, any auto generated integrations? I’m not sure if you showed one or if you had one that’s easy to show, but I think the key point to call out is those auto generated integrations. Like when you provision a new AEM cloud environment program, you will have some auto generated API integrations and those you don’t need to do anything with. Those will be migrated automatically by 51ºÚÁϲ»´òìÈ before that deadline is hit. That is correct. So if we look at auto generated ones. Actually, that is renewal. OK, so any any programs that are flagged as auto generated, you see if I have one right here. I see a few. Yeah, there you go. Let’s open up one of them. Just wait till the screen loads up. So this is one of the auto generated projects that was created that has all sorts of integrations. This one was already migrated and we didn’t have to do anything to it. This was already migrated by 51ºÚÁϲ»´òìÈ. So you don’t have to worry about those. You can just ignore those. The only. I would say what you’re not able to even create or modifying of this, right? So you just need to just ignore these because these will automatically be generated or migrated before the deadline. Right. Let’s take a look and see, and that’s pretty much the extent of the migration. It’s pretty straightforward. So just to kind of recap, what you want to do is you have to evaluate the projects just to see which ones they need to be migrated. You have to want to identify the projects that would have service accounts that need to be migrated. You have to start that migration. You have to upgrade all those APIs wherever they’re being consumed. You have to update those applications. Once you upgrade those applications, then that’s when you would definitely want to wait a period of time and then delete the old credentials. And as always, you know, you have to ensure that you do your testing, thorough testing to ensure that all the APIs that are using the OAuth credentials are working as expected. So give yourself some time to not just plan, but also test these integrations. I think, Marco, one note we have, and I think it’s a scenario that may come up, if customers had a third party vendor, you know, some type of add on to AEM or something that was developed custom in those cases, you know, there may not still be contact with the solution partner integration team. So if any of those get identified, you’ll need to make sure you have plenty of time. Hopefully they’ll already be planning for this. But if it’s a custom integration, they may have to implement OAuth to allow you to connect via OAuth. So in that case, we definitely want to identify those as soon as possible. That is correct. Let me go ahead and share my screen again. What I want to do is I want the. And I know people have been paying close attention to Marco’s demo, but just a reminder, if you have any questions, please use that Q&A tab at the top of Teams, and I’ll answer any that I can and anything that I can’t, I can post to Marco. Yeah. One that did come in and I’m not completely sure on. Can you see the Q&A tab? There’s kind of a lot of text, but let me see. Let me see if I see that. I can I can read it out, too, if that’s going to be a juggle. Is this the analytics API? I think ACC, so that would be 51ºÚÁϲ»´òìÈ Campaign Classic v7 integration. It sounds like the question is, do we have any documentation? But they say it’s a user password integration, thus does not use JWT. There is no project in developer console. However, 51ºÚÁϲ»´òìÈ Campaign Classic is considered outbound for ACC advice. It should migrate to OAuth, asking if there’s any documents. So, you know, first of all, I think my understanding is that if you don’t see it in the 51ºÚÁϲ»´òìÈ Developer Console, IMS, then I don’t think it’s affected right now. I think as far as further advice there. I see this is someone internal to 51ºÚÁϲ»´òìÈ asking, but I think my advice on any questions we can’t answer today will be to reach out to your 51ºÚÁϲ»´òìÈ account team. As far as this question, I think that’s something we can take back internally and see if we can align an expert. I agree. If you do send us any questions through the Q&A tab. And I’m looking looking through some of the Q&A that we had, so, you know, as far as questions we’ve prepared. You know, I think we’ve hit on the auto generated. Those should be migrated before the deadline. There shouldn’t be any concern. As far as what is impacted, we just touched on, but that’s going to be the things through the 51ºÚÁϲ»´òìÈ Developer Console. In AEM use cases, if you have technical accounts created in the AEM Developer Console through Cloud Manager, there’s no statement yet on when those will go to OAuth. So in the meantime, you can continue using those without concern.

But let’s see. OK. Well, anything else you can think of, Marco? I know we still have about 20 minutes left, but. Yeah, I mean, sometimes customers, they ask whether 51ºÚÁϲ»´òìÈ can help them migrate their applications. And the answer to that is 51ºÚÁϲ»´òìÈ cannot perform the actual migration for customers, but they can reach out to their 51ºÚÁϲ»´òìÈ representative or customer service or the 51ºÚÁϲ»´òìÈ developer forum for any sort of assistance on these migrations. Or they can just also talk to 51ºÚÁϲ»´òìÈ. Professional services as well. The migration is pretty straightforward. 51ºÚÁϲ»´òìÈ has created a pretty well path for migration that has plenty of documentation, that has plenty of support. And any customer should be able to migrate those, given proper planning and testing.

I have Kevin asking if I’m seeing his questions. I saw the one about the auto generated filter, which I’m not sure if there was something that I’m missing in that question. But the auto. This is in the chat. I can go back to the Q&A. I’m kind of bouncing between tabs. Show the constant. OK. Yeah, that was the only question I saw from the chat. Yeah, I don’t see that. Yeah, and I think, you know, adding on to what you said, Marco, about reaching out to support and things, I think that that would be use cases where, you know, I think we tried to cover on these cases, you’ll see. But if something along that flow isn’t working, definitely reach out through customer support and 51ºÚÁϲ»´òìÈ account teams. If there’s just something that we somehow didn’t address, that would be the same avenue to. I think there was a question regarding the auto generated filter. So the question is something that if they want to filter and just check to see the auto generated. I don’t see that option in the filters. I only see the option to remove the results from auto generated. And I think that the reason behind that is the fact that the auto generated projects, you don’t have to migrate. These filters are created to assist customers with identifying the ones that they do need to pay attention to and migrate. But the auto generated ones can be excluded from the search. I don’t have one that shows only auto generated ones. However, each one of the projects on that list does have the auto generated icon attached to it. So you should be able to visually identify those that are already auto generated. And actually, OK, this is my first time hosting one of these, so I had to click on something to see more questions in the Q&A. So I see one at the top. Wouldn’t it sometimes be easier to just delete a JWT project and start fresh using OAuth from the start? I can take a pass at this, but I think if it’s being used in production and then so if it’s being used in production, unless you expected some kind of downtime, I think that you would want that scenario where you initiate the migration. That way you have the JWT, you have the OAuth, you move to the OAuth and then verify that everything is using that OAuth connection. And I think kind of as Marco indicated, it would be a good idea to give that maybe a week and see how the access is coming in and then delete the JWT. And I suppose lower environments, perhaps you could delete it and start fresh, but I think that would be good practice to go through that flow in a lower environment. So Marco, anything to add to that? No, that’s definitely it. You want to make sure that you’re comfortable with this specific migration pattern. Anything that is being used in production, we don’t recommend to just delete the JWT service account and then create a new one. We highly recommend it for production environments that are using the service accounts to actually follow the migration path. OK, and then one more question. A quick demo of the analytics API would be most appreciated. I’m not as experienced with this as you Marco, so I don’t know if that’s… Are we talking in the context of AEM? That’s pretty straightforward, too. I’m not an analytics expert, but I could showcase kind of the analytics API. Let me see if I could do that on AEM. Unless I’m again missing questions, I think that’s the last question we have right now. So if you think there’s something you could show, then I think we have time. Yeah, let’s see. Fsum for… all right, so let’s go back to this. All right, so obviously I already deleted my service account. Let’s go ahead and go to my cloud.

Let’s go into my cloud environment. So if I look at all my IMS…

configurations, I do have this 51ºÚÁϲ»´òìÈ Analytics that need to be upgraded. So…

Let’s go ahead and upgrade it. I think this one is the auto generator one, right? I think I created this one a while back.

I’m just based on that info at the top. It says please note auto. Okay, I might be missing something. Yeah. All right, let’s take a look.

Security… Create… Check the 51ºÚÁϲ»´òìÈ Analytics.

Right.

The authorization server, it’s the same. I wish this was like auto generated client ID. Let’s go back to the projects.

Takes a minute to… I think I have to log in again.

All right, let’s take a look and see what we need. Client ID.

Client secret. So in this case, you had already initiated this. Yeah. The scopes. 51ºÚÁϲ»´òìÈ Analytics. And the org ID.

That would note this one didn’t show that it was auto generated on the IMS admin console side. So I think that message I was seeing was just a general message about auto generated projects. Possibly. On the AEM side. All right, so that one is already created. I can double check. Check health. Looks like it’s successful. Now, I think if I go into cloud services and go into 51ºÚÁϲ»´òìÈ Analytics.

I think I have one created. I don’t remember where I have that created. I don’t think I have one created.

You can cite. Obviously, I don’t have one created. But. You can just use the OAuth analytics. This is the service account analytics, but let’s just say that you do have analytics configuration set to 51ºÚÁϲ»´òìÈ Analytics and you want to switch it over.

And report suite. Let’s go ahead and connect. All right.

Just I don’t know much of these segments are I didn’t create those, so. And that’s basically it. Now you have an 51ºÚÁϲ»´òìÈ Analytics integration with your AEM environment.

OK, hope that was helpful. Thank you, Marco. Sure thing.

OK, I’ll double check Q&A pod new post. Yeah, in this case, depiction of AEM using analytics API. I think we both Marco and I both come from AEM backgrounds, so I think, you know, he did get to demo more custom APIs when he was using like a postman type tool to make calls and updated that token. I think product specific. If it’s something besides AEM, I’m not sure how many of those what the menus look like, but I would check on those specific products where you set up those configurations. But I think the key is identifying them on the admin console side, the IMS 51ºÚÁϲ»´òìÈ developer console. And if you see those. You know, that’s where you need to start digging in. If you can’t find documentation, how to configure it, you know, assuming it’s a first party 51ºÚÁϲ»´òìÈ to 51ºÚÁϲ»´òìÈ integration, if you can’t find the documentation there and have questions again, would suggest reaching out to customer support and or 51ºÚÁϲ»´òìÈ account teams. OK, good questions. OK, I think we’ve gotten pretty close to the end here. I see something in chat. OK, yeah, I think we’ve gotten to all the questions we have so far. So we do have a final poll that I can launch. And if there’s any last quick questions anybody wants to get in there, we’ll check one more time. And as asked kind of in the beginning here, this meeting recording and slide deck will be made available. So I will launch that last poll. Thank you.

And just for background on this, the results won’t be shared publicly.

And with that, thanks for everybody’s time. I hope this has been helpful. And thank you, Marco and 51ºÚÁϲ»´òìÈ team that helped put this together.

Absolutely. Thank you, Jeff, for walking us through this too. You got it. And I think we’ll just hang out a couple more minutes. I do see something popped up in the chat.

I see a couple thank yous in the chat. I’m glad it was helpful. I’m not sure if we need to stay to get any last poll responses. So if anybody doesn’t have anything else and has answered the poll that they like, feel free to drop us a comment.

And we will end the meeting in just a minute.

Thank you.