📘 Adobe Admin Console: Dear Diary...

[Doug_Den_Hoed__AtAppStore]

Welcome to the Adobe Admin Console: Dear Diary... post!

As we Workfront SysAdmins, Partners, and Adobe Support folks learn Tips, Tricks, and Gotchas about Migrating Workfront to the Adobe Admin Console, I propose we share them with each other here using short VIDEOS.

To illustrate (and set a nice, low bar for future contributors)...

I'd like to offer this 7 minute Dear Diary... Video in which I recapped a kickoff meeting with a Workfront Sponsor who'd recently received his email from Adobe that his Workfront Instance would soon be migrating to Adobe Admin Console for user authentication. It is raw and unrehearsed (and if you would like to turn captions on an count my UMs, feel free to poke fun)...but is also chock-full of things to start thinking about before you start, and took WAY less time to create than a formal presentation:

I hope you find it useful, encourage you to contribute your own Dear Diary... videos to this thread, and look forward (likely after the Adobe Summit excitement has passed) to hearing from some official Adobe Support voices (and faces), too.

Regards,

Doug

P.S. much appreciation to @CynthiaBoon for her brainstorming and encouragement on setting this one up!

Other related links...

• Migration to the Adobe Business Platform - the new Adobe Identity and Admin Console
• Announcing the Adobe Admin Console Migration Tool from 40,000 Feet
• Admin Console - Post Migration Issues?
• API Key Authentication now available! 

[Kelly_Wehrmann]

As always, thanks for the video and your insight.   

Can I get clarification from you on a few things you mentioned in the video?

At the beginning you mentioned that the latest client already had SSO and Adobe Console in place.  In terms of SSO, are you referring to them using SSO in general as an organization?  Or are you referring to them already using "Workfront SSO"?

Currently, our network group has SSO in place for some applications, however, we are not using Workfront SSO at this time.  Workfront users still authenticate using an email address and password.

You also mentioned working with Adobe Support to run a test migration using a Sandbox environment.  Currently, we do not have a Sandbox environment, have you worked with or know of any clients that were able to run a test migration using their Preview environment?  Is this a viable option? 

Our Workfront users don't necessarily know that there is a separate Workfront Preview environment, mainly because we don't advertise it.... for precisely the same reason you mentioned in your "cautionary tale" post.  We want to avoid the potential for anyone to mistake Preview for Production.  We'd like Preview to stay "hidden" after migrating to the Adobe Console so we will not include it on their Adobe Console User Profiles.  In the event that we want some people to review changes to Preview or things that we are developing, we can grant them access to the environment via the Adobe Console.

Non-video questions that I haven't gotten a clear answer from Support on that I'd like your feedback on:

1) Based on what I have read once we migrate to Adobe Console and are using SSO Workfront Admins lose the ability to use the "Login in as" option that is currently available. Can you confirm this?

If so, are there any good alternatives for the Workfront Admin to simulate another users Workfront UI experience?

2) In another post, Admin Console - Post Migration Issues? - Adobe Experience League Community - 658065, have you run into either of the reported issues:

Issue 4 - Missing Audit Logs - they have subsequently updated their post to indicate the logs have shown back up.  Was this a 1-off?  Did you see this occur before?  If so, is this no longer an issue for the latest migrations that you have participated in?

Issue 8 (Possible) - Reset of system preferences, have you run into this issue?  If so, is there a work-around?

Finally, please share your secret with the rest of us.... apparently, you have found the fountain of youth.      Not much difference between you at Leap 2019 and now!  Thanks again for sharing your experiences with the rest of us!

[Doug_Den_Hoed__AtAppStore]

Hi @Kelly_Wehrmann,

The client I was recapping in the above video has used SSO with Workfront for about 2 years now (having switched from classic username / password for may years beforehand), and were an essential part of our recent API Key Authentication now available proclamation. As customers of additional Adobe software besides Workfront, they also already have an Adobe Admin Console set up (good), which is already configured to use SSO for that other software (better), and still employ the in-house expert who implemented and that configuration (best), which is what I meant by them being in an advantageous position, when the time comes to migrate Workfront to Adobe Admin Console.

If you don’t have a sandbox (e.g. mydomain.sb01.workftont.com or mydomain.sb02.workftont.com), yes, you could (and I would recommend you do) use your preview environment (mydomain.preview.workftont.com) for testing Adobe Admin Console in a fashion similar to what I described in the video. The main difference is that sandboxes refresh upon your (SysAdmin) request, where preview gets refreshed every weekend, so your time window for complex tests is limited on the latter…but since the Adobe Admin Console setup is independent of such Workfront data refreshes, that setup effort is preserved, meaning you could then easily continue testing in preview beyond that one week window.

As per my cautionary tale post and video remarks, I think you are wise to limit access to (and knowledge of) your preview environment (and sandboxes) to avoid confusion.

I too asked whether the Login As feature was indeed going to no longer be available under Adobe Admin Console (as per a documented warning), but @JonahMc confirmed otherwise. If it ever does go away, as SysAdmin, you could resort to logging into preview (or sandbox), changing the password of a user whom you are trying to impersonate, then literally logging in as them (in a different browser, ideally, so you are simultaneously both yourself and them)…but that is of course just an approximation of what Login As in production offers.

Just yesterday I learned of another situation that matches the item 4 you cited, where audit logs were missing (or perhaps behind) and then came back (or perhaps caught up), so that does not appear to be a one off…but might also not be related to Adobe Admin Console. Either way, it warrants a help desk ticket, in my opinion.

I have not yet personally observed the behavior in items 8 about system preferences being reset, but if any Fusion enthusiasts (or Blue Print architects) care to provide an Easy Button for such an emergency, I suspect it would be popular.

And finally, as for my repeated trips to the fountain of youth (thank you for asking )…

I’ll go with “gratitude”: my amazing wife, incredible children, supportive family, lifelong friends, engaging career, and wonderful clients keep me young.

Regards,

Doug

[Kelly_Wehrmann]

Thanks for your responses.  They make me feel a little more hopeful that the migration to the Adoble Console will not be a complete disaster.  I'm especially relieved to hear you confirm that using Preview is a viable option to do some pre-testing.

As for the fountain of youth....thanks for sharing your secret ingredients!  Sound like I'm on the right path and I'm hoping to have as much success as you!   

[CBuckwal]

Hi Doug, 

Have you or anyone else had experience with the Workfront admin console migration with Workfront users with non-enterprise/non-SSO Adobe Creative Cloud and Acrobat accounts? In our testing so far, this combination has created a lot of login confusion and sometimes results in “you don’t have access” pages showing due to cache conflicts between the Adobe product accounts. We’ve worked with support and our plan is to convert all Workfront User Creative Cloud/Acrobat accounts to Federated IDs as instructed by support. But while testing this fix in our small test group, test users still see no access pages and have difficulty accessing their non-Workfront Adobe products. Also, on the Adobe login screen, it's possible to create additional personal Adobe accounts using the same email address that is used as Federated ID, which creates even more issues. Thanks for any insights on this.  

[Doug_Den_Hoed__AtAppStore]

Hi @CBuckwal,

Yes, I feel like I'm gradually seeing all of the combinations across various client, at least as far as Workfront goes: I have less exposure to (or interest in) other Adobe products. As sound like is the case for you, some combinations do indeed have some login confusion and/or "you don't have access" messaging. On any given day, I often log in to several different Workfront instances across our various clients (whether classic username / password, SSO, or Adobe Admin Console) -- not to mention our own instance -- and as I do, can offer a few tips that seem to help:

• prior to logging into an Adobe Admin Console instance, start up a new incognito tab, which helps assert your intention to "start fresh" as a new user
• in a few cases where (despite being in incognito) Adobe Admin Console it still "remembers" my old connection, I then resort to either restarting my browser entirely, and/or clearing my browser cache, and/or (usually) switching to a different browser (e.g. Firefox, if I was already in Chrome)
• when possible, I try to connect to Workfront via Adobe Admin Console using the "Business or School" option...but there are also several situations that have instead wound up being under the "Personal" option, which makes logging in a bit of a coin toss (which I somehow seem to lose more often than statistically probable)
• as others have also reported, when navigating within Workfront (and particularly "back to it", if I'd browsed elsewhere and then come back), the Adobe Login screen does often re-present itself...but I'm learning to resist the temptation to start typing in my credentials again since -- if I just wait a couple of seconds -- it then seems to remember that I was already logged in (perhaps re-authenticating), disappears automatically, and takes me to my intended Workfront destination page

Regards,

Doug

[CBuckwal]

Doug,

Thanks for your insight on this. We’ve tried incognito too with mixed results as you mentioned. I’ve heard logins work better if all the instances are in the same admin console, but we don’t have that option. We’re relatively new to Workfront and still onboarding users, so we were hoping some of the Adobe login issues would be resolved since more Workfront instances are being brought into admin console and most places use other non-Workfront Adobe products on admin consoles. This will be a tough user experience in Workfront if users have all these login issues once we're on admin console.

Cathy

[Doug_Den_Hoed__AtAppStore]

Good point Cathy,

In one instance, the IT Department went to extra lengths to not create an additional Adobe Admin Console for Workfront, instead (wisely) deciding to leverage their existing AAC so that all users could be administered centrally, and (for the most part) would then have the same login experience. A few months later, they then also enabled that one AAC to use SSO, which went quite smoothly (i.e. weeks of multiple refresh/run/repeat practice runs against their sandbox, followed by a mostly successful transition within the ~2 hour outage they'd scheduled). It's unfortunate that you don't have that option; as, I'm aware, is the case for others, for various governance / technical / budgetary reasons.

Regards,

Doug

[lindselib]

I was going to share our migration experience as we just moved on Friday 5/3. It was relatively painless and out of 200+ users only 15 really ran into issues so I count that as a win! However, the issue we ran into for those 15 I thought I'd share here as an FYI in case it can help anyone else prepare. 

Before the migration, we had a subset of users who logged into Workfront with SSO but had their email notifications routing to a different email address. In the pre-console world we would set this up by making their user profile's fedID = the email used for SSO, and the username=the email for notifications (typically a shared inbox). We would then go in and map the attributes also through the set up page. So a user's settings might appear like the below..

Name: Lindsey Brown
FedID: lindsey.brown@advisorsexcel.com
Username: sharedinbox@advisorsexcel.com
Under Attribute Mappings: If directory attribute equals lindsey.brown@advisorsexcel.com set Workfront attribute to sharedinbox@advisorsexcel.com

NOW post-migration, all users who were set up that way accidently got duplicate Workfront accounts. Their REAL Workfront account with all the right settings & layout got stuck under the "shared inbox" username, and then they were auto-provisioned a NEW account under their SSO email that was blank with no settings.

We found the "fix" to get people back in their right accounts was to 1) Deactivate both Workfront accounts, 2) Update the duplicated auto-provisioned account to have a "1" before the email address (or just put in some bogus email address, 3) Update the original account to have the SSO email and reactivate it. 4) Delete the duplicate account. 

However, unfortunately it sounds like the functionality that we had before to use one email to log in and another for notifications is no longer a thing in console We are going to solve just with Outlook forwarding rules for now- which works fine but just less clean to administer behind the scenes like the old way. We were also taken off guard by this as during prep for the move we got the impression that mappings would remain the same so that was disappointing to find out otherwise- the users would have taken it better and had less down time if we could have set it up that way ahead of time!

I've also submitted an idea here for them to bring back that functionality if anyone agrees please upvote!

[MoniqueEvans]

Thanks for sharing your story Lindsey. When you started the process did your Support Engineer flag all of the duplicate emails in the system? This has been the first step of our migration process and they gave me a list of 60+ duplicates and then found an additional 10ish when running it again. Hopefully, they don't find any more dupes on the next scan.

[lindselib]

No they weren't flagged in any way but maybe because they weren't true duplicates? Prior to the change we did ask our dedicated support person about the mappings (referring to the tab under set-up >SSO> attribute mappings) and were told "everything would carry over." But I don't think we just weren't understanding each other/miscommunicated. 

Luckily once we understood what was wrong it was a quick fix- but took a little too long to understand what was wrong haha. And the forward of emails is working but just kinda sucks from an administrative standpoint. The other way was way easier, so hoping it comes back someday!

[Randi_Rettig]

Thanks for posting Doug. I am not going to make a video as I feel it's short and sweet but relevant. We have an issue and thus have not yet moved due to notifications this would cause to external users. We use Proof in Workfront to share with vendors or clients with their email address for review. As we all know, this creates a user in Proof and in Workfront. As others may also know sometimes a user doesn't pick a user's Workfront name and accidentally creates a new user as external in Workfront by inputting their email instead of using the user account. We learned in testing an email would be sent to these external users letting them know they were invited to our Workfront and asking them to create an account once they were moved to the AAC. This email is misleading as we may have only shared a Proof and only in the past and not recently, nor do we require our clients to login to view the Proofs so would be confusing to our clients or vendors.

I was told to deactivate their Workfont user but they lose access to the Proof in testing since the Proof is still in Workfront, so this is not an option. This would also happen each time we share externally moving forward for anyone new so wouldn't fix it ongoing.

We have been in contact with Workfront and Adobe about suppressing the confusing notification without a resolution as of yet. Is anyone else experiencing this issue and any tips for how you handled?

[Stacey_Robertson]

Curious if you've found any resolution since you posted this.  We are scheduled to be migrated 12/1 and have the same issue with thousands of proof users.  Unfortunately our proof users are contributors and not external users so that poses a greater chance of this notification going out.

[Randi_Rettig]

Hi Stacey,

We were going to test in sandbox but unfortunately you can't use Proof there. The plan is to deactivate all external users, migrate, turn one test external user on and check if an email is sent, confirm if it was not (the ideal scenario) and then reactivate those who will remain active. Anyone accidentally shared a Proof as an external user who is internal will not be reactivated and the Proof owner will have to reshare to their user account. WF has told us nobody in our domain should receive an email for internal users. Our users may reach out if they want to have an external user reactivated that is older than 30 days. If any issues they said they can rollback within a minute. Our questions which we are hoping to answer soon are more related to our SSO setup as we use OKTA and also have Adobe sign set with creative folks and how this impacts any of our internal setups to make sure SSO will work as expected and how licenses will be assigned and users provisioned in the new world. We hope to migrate this month, date TBD. 

Hope this helps.

Best,

Randi

[AWoody]

Thank you! This is really valuable advice - my biggest concern is the initial UX for the user, so this is great.