No longer able to edit devices in DEP view

[dfurasek]

Hi All,

Sorry for the length of this post, but I'm attempting to drum up some community support for reverting a recent change that was made to the Meraki MDM. Please understand that all of my discussions with them have been very cordial, so I'm intending no malice towards anybody with Meraki. Just maybe I'm the only one not pleased with the change, but that would be a surprise to me. If I'm not alone, I think it would be beneficial for them to hear similar sentiments from others besides myself, so I'm encouraging others to also politely open another case to echo my concerns. So, without further ado...

A few days ago, I submitted the following case to Meraki support:

"Previously, under Systems Manager -> Devices, I could switch from the 'General' view to the 'DEP' view (in the upper-right corner) to see DEP devices that were assigned to that network but not yet actually enrolled by the setup process on the device itself. Now, I can still see those devices in the list, but if I click into any one of them, I get an error that looks something like this:

Additionally, if I switch to the Systems Manger -> DEP page, such devices appear in that list with a 'Name' that is no longer a clickable link, which is also a change from previous behavior. All of this is a big problem, because I can no longer rename a device and/or assign an owner prior to the device being activated."

...and after their initial response indicated a need for further clarification, I followed up with this:

"For the last several years until very recently (i.e. earlier this week), I have been able to access the detail page for any DEP device where the settings had not yet been pushed (a 'placeholder' page of sorts), where I could rename the device and/or assign an owner, and I could take two paths to get to that point:

1. On the DEP page, as long as I was already working in the particular network to which the device had been assigned, I could click on the device name to get to the detail page. This same device name is now non-clickable text. This is definitely a recent change in behavior.

2. On the device list page, I could change the selector near the top-right from the default 'General' option to the 'DEP' option, and from there, I could click on the device name to get to the detail page. This same action now leads to the error described in my initial case submission, and this is also definitely a recent change in behavior.

Based on what I know right now, this is a significant negative impact to my workflow efficiency, because I can no longer perform those tasks until after the device is activated."

I was eventually told the change was intentional, with the following statement from the Meraki product team:

"The intent was to avoid confusion since if the device is not enrolled there is no need for the device link to be a hyperlink to a non-existent page."

...and my last response to them (so far) was as follows:

"Until this change, the page (client details for a DEP device that was not yet enrolled) did indeed exist, and it was that way for several years. As to the 'no need' bit, I have a frequent need to change the name and/or (more importantly) assign an owner for such devices. Without that ability, I can no longer pre-configure an email profile (based on the owner) for a given device, so the experience is worse for the end-user, and my workflow is much less efficient, as I have to circle back after enrollment to take care of these tasks."

If you agree, please take action, and whether or not you agree, please feel free to discuss here. 🙂 Thanks!

[AnitaF]

I am also dealing with this issue and wish they would roll back the change.  The update breaks the process we have put in place as an organization which sounds much like yours and makes for way more manual work on my part.  There will now be a need for a manual inventory of devices assigned to a user.  Think about a mass upgrade phone order and every device being named "iPhone device" with no way to change that!  If this change remains, I believe we'll be looking for an alternate MDM solution.

[beks88]

As mentioned already in the thread below. I would recommend both of you to use MDM authentication and let Systems Manager bind the owner automatically to the device.

https://community.meraki.com/t5/Endpoint-Management-Systems/Enrolling-DEP-iOS-devices/m-p/92729#M707...

I don't want to tell you how to do or change your workflow. But give it a try. This saves our organization a good amount of time and a user can pick what ever phone is available ;).

[vassallon]

"The intent was to avoid confusion since if the device is not enrolled there is no need for the device link to be a hyperlink to a non-existent page."

This is very much untrue. I used this option quite frequently to clear Activation Locks from devices.

[dfurasek]

Yes, excellent point!  This change has also taken away the ability to clear the activation lock on a DEP device that has already been removed from the MDM for any reason, which is definitely a problem.  ☹️

[vassallon]

@dfurasek 

I just opened my own case with support and I will be pushing them hard to get this restored. 

I was in the middle of processing iPads from our Seniors who graduated when they removed this functionality last week. No instead of just clicking a button in Meraki I now have to engage Apple to clear the activation locks.

[beks88]

@vassallon

totally forgot on this, absolutely very important point. This should be considered as very high prio @Noah_Salzman

[Noah_Salzman]

Sorry for the trouble the changes to DEP have caused. We're actively looking into this and we'll be updating you later in the week. I wish I had more detail for you right now, but I thought it was important to respond to let you all know the issue was a high priority for us in advance of sharing any details.

Noah Salzman

Product Manager for Meraki SM

[vassallon]

@Noah_Salzman 

Thanks for the follow-up on this, I figured it wasn't an intentional feature. 

[Nelsonb0101]

We have to swap almost 200 phones next week in two days. This change is going to kill my team and upset our customers. Not being able to set owners and device tags before we meet with staff will greatly slow down phone swap times. Our meraki admins are reserved for making changes in meraki and wiping / removing the phones from the system. We use less skilled staff with no meraki access to perform the swaps. By taking away this ability it makes our less skilled staff useless and puts all the work on three admins to manipulate 200 phones on the fly.

[NRSITGuy]

Add me to the list that uses this feature to pre-set up devices and assign them to owners before the device reaches them. I drop ship a lot of phones straight from the cell provider, so this is crucial to having it all ready to go for the remote user to activate the phone on their schedule. It made everything convenient for IT and the end-user to get them up and running and in SM as quickly as possible. As it stands, I'd have to keep checking in with the end-user to find out when they configured the phone so I could go back into SM and assign the owner with the appropriate tags to apply settings. Please add this editing ability back to un-enrolled devices. Thanks.

[Dorpond]

I agree. I opened a case as well. We need this to roll back to the way it used to work, or else I may be forced to switch MDM's. This new change is destroying my workflow and becoming a problem with scheduling phone deployments with employees.

The new workflow (horrible):

1. I assign a Profile.

2. Tell the team to deploy the phone.

3. The team schedules time with employee to do the phone replacement. Someone from the team and the employee are both present.

4. They deploy the phone, but now they have to reach out to me again, because the phone hasn't been named, and no tags have been applied so no apps are rolling out. Hopefully I am not on another task when they call me, or else now they'll have to wait for me to get to it. If I am not readily available, now we have 2 employees that are sitting there waiting or forced to reschedule another time.

5. Finally I can get to Meraki and assign the tags and name the device.

6. I call the team mate and tell them it is ready for the next step.

Really, that workflow is terrible!

The old workflow (awesome):

1. Assign profile, name device, assign tags.

2. Tell team the phone is ready.

3. Team gets with employee and does the deployment. Done.

Please make this work the way it used to, Cisco.

[Kevin_C]

Recent changes to provide a more consistent cross-platform device deletion experience in Systems Manager appears to have unintentionally impacted a variety of customer workflows when managing Apple automated enrollment devices (aka DEP).  While we are not planning to restore access to deleted device information at this time, we are actively working on ways to re-enable, and in some cases enhance, the experience when assigning owners and renaming devices in the Meraki Dashboard. Look out for feature updates coming in the next few weeks!

[beks88]

@Kevin_C I think there are two point of views regarding these changes

First and in my opinion the most important. Because of the recent change, no one is able to delete activation lock from DEP devices (Systems Manager - DEP) if they've been deleted from the device list (Systems Manager - Devices)

Second is the problem with user assignment. As already mentioned, I really would recommend to all who use the DEP interface for assigning users and tags to turn MDM authentication ON and let Systems Manager do the work on enrollment.

I'm also interested, why so many still aren't using MDM authentication. I'm open for a discussion PM me on this 🙂

[dfurasek]

@Noah_Salzman @Kevin_C

Thank you for taking the time to post in this forum, it is much appreciated. Please, please, please reconsider your decision.

In addition to renaming devices and assigning owners, there is also the even more important need mentioned a few times in this thread to disable the activation lock. (If you have ever needed to contact Apple to have that done on their end, you know that it is not at all a quick and simple process.) Those are at least three concrete features that have been removed by this recent change. With respect, what I'm hearing are vague things like "the intent was to avoid confusion" and "more consistent cross-platform device deletion experience" as far as improvements due to the same change. In other words, try as I might, I'm really failing to see how the benefits outweigh the costs.

If there truly are better ways to perform (all three of) these tasks coming down the pipe, that's good to hear, but what you had before worked just fine, so it would certainly seem to be simpler to just go back and not reinvent that wheel. If the decision stands, I guess that's ultimately your call, but would it be possible to at least temporarily revert until those enhancements are ready for prime time? Better yet, could you go back to the old way and eventually add the new way as a second alternative for those that choose to use it? Again, I may be missing something, but I don't see how that would be a bad idea, especially since I think we're just talking about restoring access to the exact same page that is still available for actively enrolled devices.

Finally, we are a paying Meraki customer with hundreds of wireless access points, but in the interest of full disclosure, we are currently using the "legacy" MDM for free. We have accepted that the free MDM does not have nearly the feature set of the paid MDM, but it does what we need it to do, so we have found ways to deal with the lack of the newer features. In this case, certain fundamental features that existed long before Meraki switched to the free/paid model have been actually removed, so I would very much hope the new enhancements that were mentioned will be made available to both free and paid MDM users.

Thanks again.

[vassallon]

@Kevin_C 

Thank you for communicating this with us, one of the huge issues about all of this is that there has been ZERO communication about this changing or even going away. This functionality just disappeared in the middle of the day with no warning at all. 

Here's a thought, maybe reach out to your customer base ahead of time and ask how a MAJOR change like this will affect them. I know myself and others would have had plenty of feedback to share.

As @beks88 said, on of the biggest impacts is that we now have no way of clearing activation locks which is now a huge time suck that would have been fixed in a few clicks within Meraki before.

[vassallon]

@Kevin_C @Noah_Salzman 

You know the whole point of a MDM is to make people who administer the devices job easier. Right now with all of the undocumented and unannounced changes that have been made that is far from the case. Please stop making changes that make our jobs harder. 

I have been a Meraki advocate since I got to my district and started using the product but it's getting harder and harder to keep justifying the cost. I don't know if in good conscience I can recommend staying with Meraki as our MDM especially when there are cheaper options.

It's starting to feel like you are losing touch with your customers and I'm getting to the point of I'd rather learn a new MDM that will listen and appreciate my feedback then wait to see what is next that makes my job harder from Cisco/Meraki.

[Noah_Salzman]

"Never take down a fence unless you know why it was put up in the first place."

First, please accept our apology for the hassle and annoyance. Our intention is never to make someone's job harder.

To emphasize what Kevin already wrote: the negative impact of this change was unintentional and we are working right now to get you the features you need to have a reasonable workflow. The upcoming changes will not give you exactly the same workflow. Why? The starting point for this mishegoss was a desire to solve issues many of our users were having with deleted devices in the DEP device list… the "fence" in the aphorism above. So, rather than a simple revert, we will be creating a new workflow around DEP devices. That work is underway now. It will be weeks, not months, to complete it.

Without question, this event has caused us to reflect seriously on this type of change and how we can do better to understand the impact of these types of changes. This was a big swing and a miss, we get that. 

Later this week we'll share a rough sketch of the changes that are coming to get your feedback and ensure we are on the right track to fixing this.

Noah Salzman

Product Manager for Meraki SM

[dfurasek]

@Noah_Salzman Thank you for the sincere reply. I look forward to your forthcoming update on the changes that you are planning.

[NRSITGuy]

Thank you for the update and insight into the steps moving forward on this. Much appreciated to know something is being worked on to address this.

[vassallon]

@Noah_Salzman 

I appreciate the response but one of the biggest issues is still lingering. MDM changes are made and it feels like there is never any documentation on the changes.

A major change like this should have been documented and we should have been notified before/when it was turned on. 

[denise_g]

I completely agree that this feature needs to be restored. I'm lucky that I had recently added needed information to new devices in DEP prior to our device upgrade that is ongoing. Being able to edit the details in devices prior to enrollment has been very helpful.  I'm glad to read that restoration of this feature is being looked at.

[PeterJames]

Just this wall myself - What is the latest from Meraki?

Thank you,

Peter James

[dfurasek]

I haven't heard anything since @Noah_Salzman indicated that a "rough sketch" of their planned changes would be forthcoming in this forum, but I have seen some signs that something is in the works, such as the addition of an "owner" column on the DEP page in the MDM.

[Noah_Salzman]

Sorry for the delay folks, we'll have an update later today.

[Kevin_C]

To restore workflows, we plan to release the following actionable command buttons on the DEP page:

• [Change Owners] Assign/change owners to any DEP-synced device.  For organizations that associate owners with devices but do not employ user authentication as part of their enrollment workflow, this button will allow admins to link owner tag-scoped configurations and apps to DEP-synced devices before enrollment.
  ETA: Mid August
• [Clear Activation Lock] Issue Clear Activation Lock commands for targeted devices. Systems Manager will also display Activation Lock bypass codes in the DEP device table. For organizations who leverage Activation Lock, this provides a method to attempt an Activation Lock bypass even after device information has been deleted in Systems Manager.  
  ETA: Late August / Early September

• [Rename Device] Change name of a single device or target multiple devices for bulk naming with unique incremental values (ie. iPad 1, iPad 2, etc).  For organizations who rely on unique device naming this provides an efficient method to rename DEP-synced devices before enrollment.
  ETA: Mid September

[dfurasek]

@Kevin_C that sounds great!  Will this also be available to users of the "legacy" MDM?  Please say yes...  🙂

[PeterJames]

Hi @Kevin_C ,

Thank you for this update.

Previously we could apply Activation Lock (to a device tagged with 'Allow Activation Lock' via Settings->Profile) on the DEP page. Will this be re-introduced?

In our case, a device has gone missing in transport and we wish to push the device to have an activation lock. In addition to that, we may delete a device off the SM but might want to again, push an activation lock on a missing or lost device.

Thank you,

Peter James

[dfurasek]

@Kevin_C and @Noah_Salzman  I see that all three of these new features have now been implemented on the DEP page, and it looks great.  😊  Thanks!!  However, while changing owners and device names works perfectly, clearing the activation lock from there appears to require the licensed version of the MDM.  As a legacy MDM user, I can still clear an activation lock on the device detail page for an enrolled device just as has always been the case, so I'm guessing/hoping that the inability to do the same from the DEP page was maybe just an oversight at this point, right?  Please advise, and thanks again.

[dfurasek]

@Kevin_C  and @Noah_Salzman 

Update: I was just told by tech support that legacy MDM users will not be able to clear activation locks from the DEP page, and here is what I sent back in reply:

"So, that was intentional?? If so, I fail to see the logic… The new features on the DEP page were added to mitigate the recent removal of the device detail pages for DEP devices that were not actively enrolled in the MDM. In other words, features were taken away (for both legacy and enterprise users), and this was done to put back equivalent means to the same ends. As a legacy user, the modification of owners and device names works great, but I can no longer clear an activation lock on such devices. When the free/paid pricing model was adopted a few years ago, it was understood that legacy users would not get most new features but would continue to be able to use existing features. As of now, this one important feature has been taken away from us, and I am respectfully asking to get it back. Again, we are indeed using the MDM for free, but we are also a Meraki wireless customer with hundreds of APs, so I would hope that counts for something. If it is to remain as is, I would very much appreciate some sort of official statement to that effect, and if possible, having that backed up with sound reasoning would also be most appreciated. Thanks again."

Would one of you gentlemen be able to please comment on this?? Again, I very much appreciate all of your efforts to make this whole situation right, but it seems there is still one small missing piece of the puzzle, which could (and I think should) be easily resolved. Thanks!

PS - I used the other two features (device names and owners) just this morning, and I was very pleased with the new workflow.  🙂

[Noah_Salzman]

Hi dfurasek, I'll look into this and get back to you. 

[PeterJames]

Hi @Noah_Salzman,

Thank you for reversing this change.

Why cant you enable Activation Lock for an individual device if the privacy setting is is not ticked? The below only states that DEP enrolled devices will have the activation lock enabled by default at enrolled. I do not understand why this blocks locking devices on an individual level.

Error on SM Platform when not ticked:

Thank you,

Peter James

[PeterJames]

Hi @Noah_Salzman ,

I should probably add that a workaround to the above;

1. Create a new iOS 'Privacy and Lock' profile / payload only applying to devices with the tag 'AllowActivationLock'

2. Tick 'Allow MDM Activation Lock'

3. Apply this tag to the device you want

4. After step 2 you can then apply the Activation Lock to the device without issue

5. Once applied you can remove this tag

I can also see the payload / profile ordering does not matter.

Thank you,

Peter

[Dorpond]

It's been months now and I still have to break up a device deployment into phases (add device to profile, wait for IT to sit down with employee to setup phone, and then wait for a phone call from them for me to name the device and add tag to deploy apps, then wait for all the apps to roll out, then contact IT staff to finish up the deployment)... *rolls eyes*.

It was so much easier when I could add the profile, name the device, and add the tags, all in the initial first step...

Time to be looking for another MDM. Sorry Meraki, but you screwed my workflow, big time.

[CBOE]

I too need the functionality restored!!  My workflow is also in shambles because of this change.  I need to remove the activation lock and set device names in the DEP view (before the device enrolls in management).

Please.....

[Mark24]

Need this changed as well has completely ruined our whole deployment plan for devices.

[dfurasek]

Hi @Noah_Salzman 

Regarding your post from ‎09-03-2020:

"Hi dfurasek, I'll look into this and get back to you."

...is there any news on the activation lock removal piece for non-enrolled DEP devices in the legacy MDM?  Thanks again.

[Kevin_C]

The ability to (re)assign and remove owners from DEP-synced devices is now available from the toolbar in the DEP devices list.  Check out this New Features post for more information.  

[dfurasek]

@Kevin_C  Nice.  🙂  Thanks!

[lahddah1]

I'm with everyone else. This change has severely hindered the way we do things. We need to be able to assign all of this information prior to the devices being sent to the user out in the field or remote offices. Relying on the user to consistently do something with their device is simply not realistic. We need to be able to assign a name w/ a standardized standard (full name, device) prior to the end user receiving the phone. Otherwise, we're just looking at a ton of 'iPhone' getting activated and cannot user Meraki to confirm who any of the devices are assigned to. Not to mention (again) the activation lock release being unavailable.

Maybe I'm missing something about the 'owner' field that others are happy about. To me, that doesn't do what we need. If it is expected to be an email address, honestly, not all of our users have an email address. What then? I'm open to a better, more streamlined process if there is one and I just need to go through some training, but I've been doing this for years and it just worked.

I know we were told here that a resolution for the 'details' issue is in the works, but in my currently open case in Meraki, I was told as recently as yesterday late afternoon/evening:

"Unfortunately that change is permanent and always be like this moving forward according to our Development Team. DEP devices will not be clickable until they finish enrolling and go through the setup wizard. Support do not influence or have the ability to change this or revert back to previous state. They have marked that behavior as an expected change"

[PeterJames]

Someone just posted the following but then it got removed (???)

Merkai Response: "Unfortunately that change is permanent and always be like this moving forward according to our Development Team. DEP devices will not be clickable until they finish enrolling and go through the setup wizard. Support do not influence or have the ability to change this or revert back to previous state. They have marked that behavior as an expected change"

If this is true, it makes me very nervous.

[lahddah1]

Thank you, PeterJames. That was my reply and I'm trying to figure out why it was removed. I went in to edit a word and then it was all gone. I guess it was listed as 'abuse' or spam or something because I edited it. This is what it said:

I'm with everyone else. This change has severely hindered the way we do things. We need to be able to assign all of this information prior to the devices being sent to the user out in the field or remote offices. Relying on the user to consistently to something with their device is simply not realistic. We need to be able to assign a name w/ a standardized naming standard (full name, device) prior to the end user receiving the phone. Otherwise, we're just looking at a ton of 'iPhone' getting activated and cannot use Meraki to confirm who any of the devices are assigned to. Not to mention (again) the activation lock release being unavailable.

Maybe I'm missing something about the 'owner' field that others are happy about. To me, that doesn't do what we need. If it is expected to be an email address, honestly, not all of our users have an email address. What then? I'm open to a better, more streamlined process if there is one and I just need to go through some training, but I've been doing this for years and it has just worked.

I know we were told here that a resolution for the 'details' issue is in the works, but in my currently open case in Meraki, I was told as recently as yesterday late afternoon/evening:

"Unfortunately that change is permanent and always be like this moving forward according to our Development Team. DEP devices will not be clickable until they finish enrolling and go through the setup wizard. Support do not influence or have the ability to change this or revert back to previous state. They have marked that behavior as an expected change"

[vassallon]

@lahddah1 

Well owner information can be set to however you like, that is easily importable through CSV files. I'm glad they have given us back some limited functionality like that. 

They have also said they are working on implementing a fix to allow for Activation locks to be cleared from DEP enrolled device which would be nice, I'm tired of having to contact Apple when I should be clicking a button. 

I hope they give us an option to set a name onto DEP enrolled devices, which they should be as we can make names match the dashboard through restrictions. 

It was just INSANELY DISRESPECTFUL to us end users how the whole thing was implemented as there was no announcement of any kind it was just gone.

Hopefully with all of our venting they will be more considerate when making a massive work-flow affecting change and actually reach out to end users before making changes like this in the future. I mean if they had just asked, I'm sure several of us would have been like wait hold up what about this feature and they could have taken it into account before making this change.

[Noah_Salzman]

Hey Vassallon, 

I understand you are mad, you have good reason to be. However, if you find it useful for the SM team to engage openly on issues like this, and not get corporate boilerplate answers, you need to understand that we are people capable of making mistakes who care about making a product that helps you.

As Kevin outlined a few days back, one part of the fix has been delivered and more are coming. It's never as fast as we would like, but we will get there.

As I stated above: we didn't communicate the change because we didn't think that change needed to be broadcast.  To your point, we do engage with users and ask how they use the product but we can't do it for every change. The key error was completely failing to recognize an existing workflow you and others rely on. Had we recognized the impact we would have treated it differently. That lack of recognition was the issue; not some casual disrespect and dismissal of the potential impact.

I ask for your continued patience as we fix this. I will understand if that is too much to ask but please know one of the worst feelings for us is knowing that our product is making your work day more difficult rather than making it easier. 

Sincerely,

  --Noah--

[vassallon]

@Noah_Salzman 

I do appreciate you guys reaching out after the fact and realizing the impact this has had on the end users.

I love using the Meraki MDM and just want it to be the best product it can be and help make mine and everyone else job easier. 

I know the team is working to make changes to fix the damage that was done, with the beginning of the school year being upon some of us having to wait for changes to be implemented is very tough.

I hope you know I am always available to try to make things better and test things out to assist in any way that I can.

[PeterJames]

Thanks @CarolineS  and @Noah_Salzman 

[CarolineS]

---

@PeterJames wrote:

Someone just posted the following but then it got removed (???)

Hi @PeterJames and @lahddah1 -

I am so sorry; for some reason @lahddah1's post got removed by our automated spam-detection system. I have now restored it (which maybe isn't that helpful since lahddah1 already re-posted... sigh). Our spam-detection system is very helpful for automatically removing many spammy posts ("love marriage problem solution", anyone?) - but sometimes it's over-aggressive and a bit unpredictable. Again, apologies!

Cheers!