Accurate Bug Updates Through Connect
It's quite frustrating to spend time logging bugs with ConfigMgr through Connect only to have bug submissions either incorrectly closed (i.e. closed as a duplicate but also closing the referenced bug - will it ever get looked at if all active bugs are closed!?) or being closed as fixed but not adding any information as to what the fix is or when the fix will be released.
Myself and colleagues spend the time and effort documenting these bugs with your products on behalf of customers so the very least that could be done in return is to let us know what is happening with them and ensure that this is communicated back to the person raising the bug.
AdminCathy (UserVoice Admin for ConfigMgr and Intune, Microsoft Endpoint Configuration Manager) commented
Thanks for sending the list, Jonathan.
When I saw your post I was afraid we had a lot of bugs that were languishing but they’ve been fixed and two had replies from our engineers. It probably wasn’t as much feedback as you wanted.
I know when a bug is fixed, we aren't necessarily telling you what the fix is. In some cases, like if X wasn't doing Y, the fix is just to make X do Y and there's not much more to be said. In other cases, we might tell you, but in many cases without the context the answer might not mean much. And I guess I have to ask why it matters what the fix is – if the problem had to do with caches or hashes, does that change anything? Sometimes if there's a tricky root cause, the engineer will document it in the bug description, but most of the time they just fix that bug and go onto the next.
I can also understand that it’s frustrating for you not to know the exact ship vehicle, but maybe this will help explain why. I’ve been at Microsoft for 13 years, and most of that on this team. I’ve seen bugs get resolved as fixed, only to find the fix created a different or related problem. And while it’s rare, we have definitely backed out fixers at the last minute, if the regression was worse than the original bug. So I can look at these and say yes, they’ve all be fixed, or are duplicates of something that has been fixed, and they will probably be in the vNext release, but I would never bet my kid’s college fund on it.
Here’s the detail on each bug:
It looks like Heidi, the PM for this, responded on June 9 saying:
"Thanks a lot for sending the feedback! We are tracking a similar item (http://connect.microsoft.com/ConfigurationManagervnext/feedback/details/1344094/software-update-group-deployments-to-a-collection-right-click-error ) already and hence resolving this one as a duplicate. Please reference to the other feedback item for the resolution."
I looked at feedback ID 1344094 and I see where you replied on June 12. Shortly after you replied, Thorsten Lau posted a workaround for the issue:
"As a workaround:
Close your admin console. Open it again and do not go into "Asset and Compliance/Collections", but into "Software Library".
Fortunately, you can edit the Deployment properties there, iff you have not gone into Collections node during this Admin console session.
(You may also edit deployment properties from within the "Monitoring" workspace, but you cannot enable/disable deployments there.)"
I just added to 1344094:
Looking at the internal details, this was marked Severity 1 and Priority 1, so we took it seriously. It looks like a fix was taken for the vNext release. I don't know if that means it will show up in a TechPreview, but should be in the final release. The notes also indicate that the bug was cloned for our sustained engineering database so it can be fixed in a future cumulative update.
from the internal notes it looks like a change was made to how the hash values are calculated. I’m not sure why that would make a difference, but I added the hash value comment to Connect and reminded the engineer about the Connect tab, just in case.
This bug is a duplicate of a bug opened earlier based on feedback from our own IT department. (They alpha test what we make before you get it!). We tend to take the earliest bug filed and resolve the others as duplicates of the first one. Unfortunately this sometimes creates issues with Connect follow up, since it can break the chain of feedback. The original bug was fixed on July 10, so it wouldn’t be in the most recent tech preview. I’m pretty sure we haven’t announced if and when there will be additional tech previews, so I can’t say if you’d see the fix before vNext.
On this one, Bob, one of our engineers, responded on June 19 and said he tried to reproduce it and couldn’t so it was resolved as “not reproducible”. I see you replied later that day to say you’d reopened the bug and included more information. You say it’s similar to the first one in this list, and as I said up there, that one is fixed.
Again, sorry if we can't always provide as much detail as you'd like about what the fix was and when you'll see it. But I am glad to say that we are getting things fixed for you!
Jonathan Conway commented
Apologies for the delay and thanks very much for taking the point seriously and responding so quickly – much appreciated.
Examples below. Some of them were closed as “fixed” so I’ve just reopened them as Active but never get any responses: