Fit_Indication_2529

Last check-in: recent Status: failed/maybe/not applicable/pending/¯\\\_(ツ)\_/¯ Logs: go fish Schedule: allegedly

In my experience, the best approach is not to challenge the CTO directly or turn every tooling decision into a fight. Instead, make the operational impact, security risk, and compliance exposure visible, document it clearly, and get leadership to acknowledge the tradeoff. It also gives the CTO a clear explanation of the risk and makes ownership of the decision explicit. If leadership chooses not to approve remote access, endpoint protection, local support, or other compensating controls, then the resulting support limitations, downtime, and compliance exposure should be documented as part of that decision.

Crash Cart?

Don’t quit impulsively, but stop treating this like a normal apprentice role. Ask for a formal meeting, get responsibilities in writing, refuse to be the sole owner of critical systems, document everything, and start quietly looking at other jobs. If they want you to act as sysadmin/lead, they need to pay/title/support you accordingly. The real move is: be helpful, but do not become the life-support machine. There must always be 2 or you will never have a vacation or time off.

Anyone else looking for the rest of the story? Is this a Vent, a story what's going on here?

Yes, this is basically "standard work" in a mature IT environment. Not every internal IT action needs to be a user-facing support ticket, but firmware updates, configuration changes, maintenance work, and other noteworthy admin actions should usually be recorded somewhere. Depending on the org, that might be a change record, an internal ticket, a maintenance log, an SOP checklist, or a formal change-management process.The important part is that there is an audit trail: what changed, who changed it, when it changed, why it changed, and what the rollback plan was if something went sideways. This also builds a knowledge base of how to change things and what systems are dependant on what.

Secondly this doesn't work. `setup.exe --uninstall --force-uninstall` or registery remove the greyed out uninstall by changing the NoRemove to 0 in `HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Microsoft Edge` If not present add it with value 0 "- WebView2 uninstall is blocked: “Browser/WebView is sticky, uninstall not allowed”"

Why not? This was a controlled troubleshooting scenario on a system already in that channel. The value was tracing the failure through Edge/WebView2, dependent apps, registry and policy state, installer behavior, downgrade restrictions, and rollback limitations until a non-reimage recovery path was found. That is useful practice because the exact bug is not the point. The recovery pattern is. A bad shared component breaks dependent apps. Normal repair paths fail. Policy/channel state matters. Installer flags matter. Documentation matters. Recovery without flattening the box matters. You may not choose that lab for your staff. Fine. But after three decades in IT, I promise you this: the people who can calmly work through ugly, unsupported, half-broken states are the ones you want around when a real outage hits.

You are arguing against a point I did not make. I did not say this exact beta bug will ship to production. I said practicing recovery on ugly beta failures builds useful skills for real incidents. The exact cause changes. The pattern does not: bad update, shared runtime breaks, dependent apps fail, uninstall path blocked, downgrade path blocked, policy/channel state matters, registry state matters, MSI flags matter, and now you need a workaround that does not involve flattening the box. Reimaging was not the lesson. Avoiding the reimage was the lesson.

u/Longjumping_Law133 Microslop? If Microsoft disappeared tomorrow, the problem would not be “oh no, Word stopped working.” You would not just lose some boring enterprise software stack. You would lose a huge amount of the plumbing modern life quietly depends on WORLD WIDE. Grocery stores, banks, hospitals, utilities, payroll systems, logistics networks, schools, governments, factories, authentication systems, endpoint management, email, identity, databases, cloud workloads, vendor apps, and a thousand ugly-but-critical business processes would all start feeling it fast. Most people do not notice infrastructure until it fails. That does not mean it was unimportant. It means it was doing its job. Microsoft is absolutely fair game for criticism. Bad updates, broken recovery paths, licensing nonsense, support gaps have at it. But “microslop” is not analysis. It is just noise. If something failed, say what failed, why it failed, and what the recovery path is. That is where the real work begins.

That is exactly why Insider builds exist. We are not running them because we expect production-level stability. We run them so we can test internal applications, management tooling, browser dependencies, WebView2-hosted apps, and other software Microsoft does not have installed in their own test matrix. The useful part here is not discovering that “beta software can break.” Everyone knows that. The useful part is identifying the failure pattern and finding a workable recovery path before a similar issue reaches a broader/stable release channel. In this case, the problem was not just Edge Beta being unstable. WebView2 is a shared runtime, so the failure affected Teams, Outlook, Widgets/WebExperience, LinkedIn, and other dependent apps. Normal recovery paths were also blocked because the runtime was sticky and the stable Evergreen installer would not downgrade over the newer beta runtime. That is why I asked here: to see whether anyone else had seen the same pattern and had a cleaner workaround than reimaging.

The point of testing this stuff is to learn how to recover when a bad browser/WebView/runtime update breaks dependent apps. WebView2 is not just “a browser”; it is a shared runtime used by Teams, Outlook, Widgets, and other apps. When it breaks, normal rollback/removal paths may not work. Practicing on beta issues builds the same troubleshooting skills you need when a bad production patch hits a real environment. In this case, changing the EdgeUpdate TargetChannel back to stable and running the Edge Enterprise MSI with `ALLOWDOWNGRADE=1` got the machine back into a usable workaround state.

u/Odd_Development THANK YOU. This is the kind of things I was looking for. In this case, changing the EdgeUpdate TargetChannel back to stable and running the Edge Enterprise MSI with `ALLOWDOWNGRADE=1` got the machine back into a usable workaround state.

"Why would you run a beta version in a place where you expected stability?" Who said I expected it to be stable, I was looking for a fix. Secondly if you get gud at fixing beta problems then when a patch that hits that was released goes bad in your environments you have the skills to fix it.

When do you patch your servers? Should be at least once a month. If not its not if you get hacked its when.

Yes, it is beta. That is why I’m asking in a forum full of people who run this stuff and may have already seen the same failure pattern. The issue is not “beta software has bugs.” The issue is that WebView2 is a shared runtime, so when this build breaks, it can take Teams, Outlook, Widgets/WebExperience, LinkedIn, and other WebView2-hosted apps with it. The normal recovery options are also blocked because the runtime is sticky and the stable Evergreen installer will not downgrade over a newer beta runtime. I’m looking for confirmation, workarounds, or whether anyone has found a clean way out short of reimaging.

spit my coffee out that was a good one. Also I don't disagree with your rant.

This rant is basically: 60% valid operational criticism 20% nostalgia 20% “old man yells at cloud infrastructure”

Disclaimer I do not work for Citrix \~ A lot of people are underestimating the hidden costs of moving 100k users back to fat clients.You’re not just removing Citrix. You’re reintroducing a whole class of problems centralized app delivery used to absorb for you. * SCCM/Intune/package engineering workload explodes * App testing matrices become massive * WAN utilization increases * Helpdesk ticket volume rises * Endpoint hardware requirements go up * Security exposure expands outward again * Remote contractor access gets harder * DR gets more complicated * Legacy apps suddenly become everybody’s problem again And one of the biggest things organizations forget: Citrix was really good at abstracting terrible applications from terrible networks. A badly written app running beside the database in a XenApp farm can feel perfectly fine. Move that same app to 100,000 desktops across the country and suddenly every chatty SQL call, every inefficient lookup, every hardcoded timeout, and every ancient dependency becomes visible. A lot of applications that “worked great in Citrix” were really just being protected by proximity to the backend and extremely optimized display protocols.

Same, its like asking a car mechanic friend to work on your car for free. Parts and labor.

heard

load "$",8,1

I would recommend communications to the people that are your customers. Example: "Hi everyone, As many of you know, there’s been a leadership change in the IT division, and I’ve stepped into that role over the past few weeks. I’m aware that past interactions with our team may not have always been easy or productive. I’m not here to rehash any of that—but I do want to be clear that going forward, my goal is to make IT a reliable, professional partner to the business. Here’s what you can expect from me and the team: * Clear, respectful communication * No surprises or unnecessary gatekeeping * Decisions explained when they impact you * A focus on solving problems, not assigning blame If you’ve had issues in the past and chose not to engage with IT because of those experiences, I understand. I’d encourage you to give us another try. My door is open, and I’m actively working to rebuild trust and improve how we operate. At the same time, I want to be transparent that accountability will go both ways. We’ll do our part to be responsive and professional, and I’ll expect the same in return so we can move forward productively together. If you have open issues, concerns, or just want to reset the relationship, feel free to reach out directly."

Stop trying to prove it’s Microsoft’s fault every time. Start setting expectations that this is how cloud systems behave. There are trade offs when you go to SaaS.

Next time you're on the floor, hit them with: * “Where is long-term memory stored, exactly?” * “Can I fully disable learning/persistence?” * “Show me the data flow diagram.” * “What identities do agents assume when calling APIs?” * “How do you prevent prompt injection from altering behavior?” * “Can I replay and audit every decision deterministically?” Watch how fast the smiles get tighter.

u/Upbeat-Chain-3155 , Right now you’re operating in “how mode.” And you’re good at it. You figure out the right implementation, you secure it properly, you follow best practice, you get it done. That’s solid engineering. But I think they’re evaluating you in “why mode.” And here’s the part nobody tells you early in your career: at some point the criteria changes and nobody sends you the memo. One day you’re the hero for closing tickets fast and implementing clean solutions. The next day you’re being judged on whether you’re thinking three years ahead and aligning to business direction. That shift is invisible until you run into it. And to see it happen to someone on a contract is surprising, it looks like they hired you but really expected someone more. “How mode” is: What’s the right configuration? What’s the secure way to do this? What does Microsoft or the compliance doc say? “Why mode” is: Why are we doing this right now? Why this tool instead of something else? How does this reduce risk in a way leadership actually cares about? Is this still going to make sense in three years, or are we creating future tech debt? That’s the difference. A tactical engineer closes the gaps they’re given. A strategic engineer decides which gaps are worth closing in the first place. You’re not failing. You’re early in that transition. And honestly, at 23, being strong in the “how” layer is exactly where you should be. The “why” layer comes from seeing systems age, budgets shift, tools get replaced, and watching how decisions ripple. This isn’t about you not being capable. It’s about you leveling up from execution to perspective.

That can work too, it depends on your situation and your (the business) risk tolerance.

u/ShopBug you need to look at Windows LTSB/LTSC + Office LTSC. For your systems that can't tolerate monthly changes. For your office workers they can be on the normal version.

it is a new disc or one you took from another system? Either way make sure are running your process as admin.

yeah there are no windows in the basement sub level 3e

IT doesn’t say no to bad decisions. IT says “yes, and here’s who owns the risk.” Once decisions are attached to names, dates, and measurable fallout, the conversation changes tone immediately. A few ways to think about leverage without turning IT into the villain: IT translates technical risk into business language. Not “Windows 7 is insecure,” but “this system will fail audit X, void cyber insurance coverage Y, and require Z hours of compensating controls per quarter.” Now it’s not an opinion, it’s a cost center with a receipt. IT documents divergence, not defiance. You don’t block the Mac exception. You record that it’s non-standard, unsupported, and excluded from normal SLAs. If it breaks, it goes to the bottom of the queue. That’s not punishment, that’s physics. IT time-boxes exceptions. Every exception has an expiration date. If leadership wants to renew it, they have to consciously re-own it. Nothing scares decision-makers like having to re-approve their own bad idea every six months. IT escalates risk upward, not outward. The mistake is arguing with Marketing. Marketing isn’t the leverage point. The leverage point is the person who signs off on risk acceptance. That conversation is calmer, shorter, and strangely effective. And the most important mindset shift of all: **IT is not responsible for outcomes it explicitly warned about.** That doesn’t mean “I told you so.” It means “we implemented what was approved, and the impact matches the documented risk.” That’s accountability without confrontation.

I reply because my answer could be helpful to others.

Figure out what your risk profile is first. Designing and maintaining elaborate security systems to protect assets that do not warrant that level of protection is a misuse of limited resources. Every layer of complexity has a real cost, time, money, operational friction, and human error. When the impact of compromise is low, over-engineering the controls does not increase security; it dilutes focus from the systems that truly need strong protection. Effective security is not about protecting everything equally, but about aligning effort with risk and consequence.

Somewhere, Windows XP is smoking a cigarette behind a dumpster whispering, *‘I ran forever… and I never asked for a dime.’*

The Crow This one hurts people’s feelings, so let me be precise. Visually? Still stunning. Soundtrack? Untouchable. Story? …thin. As a teen, it felt profound because it validated *pain as identity*. As an adult, it feels emotionally monochromatic. Everything is grief, forever, at maximum volume. It’s not bad because it’s moody. It’s bad because it mistakes aesthetic intensity for thematic depth.

You know this one hits hard, I bet they are out of style too. Well mine are always out of style unless you are from the 80's and 90's

Same thing happened back when SharePoint indexing starting surfacing permission rot. LLM's are a new tool but same problem.

haha plausible, I stopped caring about naming conventions after my 1282nd reminder was ignored again.

Finally someone asking the important questions.

Sometimes it better to pay for extra bandwidth. Sometimes it isn't available so you build out your physical site.

Right now the only thing I at that functional levels are Greenfields and labs.

The free stuff is cheap, you can get pro lvl software that images converts to digital indexes it, controls metadata from the document or can be added using data tables and associations

this is terrible for thousands of pages. A doc here or there sure but when you need to scan hundreds of thousand of pages a year you quickly figure out a new plan.

Holy hand grenades batman, my scripts are functional not polished, so AI writes all the notation on what it is doing, and fills in comments and helps me organize it, its great at putting in logging and error handling so you can find where the problems are. Its like having a flunky I can say here is the script do all the boring parts please

No this is the same as it always has been, just the house of cards gets built up higher and higher. Time to exploitation from release to hack is much shorter. More people are educated on how to do it. There has never been a shortage of bad code AI or not.

Yes, the Mouth would fall off all the time.

Most technical learners (especially autodidacts) experience “the Dunning-Kruger flip.” When you start learning, you overestimate your ability; when you actually *know more*, you realize how big the field really is, so you underestimate yourself. True competence often *feels* like ignorance, because your frame of reference keeps expanding. What really fuels burnout in that post is **expectation debt**: your internal model of what “competent” means keeps inflating faster than you can “pay it off” with real experience. Every time you learn more, the goalposts move. The cure isn’t more certs or grinding it’s recalibrating how you interpret evidence of competence. You need to start recognizing that discomfort isn’t proof of inadequacy; it’s proof you’re still learning in a field too broad for anyone to fully master. No one feels confident handling *unplanned* help requests at 22yrs. The experts just got better at calmly Googling and faking composure while debugging. If you want a framework: Competence = what you can do. Confidence = what you *believe* you can do. Imposter syndrome = the lag between those two catching up with each other.

1. Learn the lay of the land before touching anything. Build a complete picture of what the MSP manages. That means: * Get copies of all contracts, credentials, configurations, and network diagrams. * Ask for exports of Active Directory (if any), M365/Azure, backup configs, firewall rules, and DNS settings. * Check what’s under warranty and what’s managed through vendor portals (Dell, HP, Meraki, etc.). * You can’t reclaim control if you don’t know what they’ve actually got their hooks in. 2. Build relationships before burning bridges. The MSP is technically still the IT department for now. They can either make the handoff smooth or make it painful. Play nice, learn their systems, and only start pulling back control once you’re confident you can maintain it. 3. Establish a baseline and start documentation. Inventory everything, users, devices, licenses, servers, network gear, internet circuits, software, and vendors. Use PowerShell or tools like Lansweeper or PDQ Inventory to speed it up. That inventory becomes your first real map. 4. Use the new building as your test run. If they’re re-cabling and moving, get involved early, review the proposals and make sure: * They’re using CAT6 or better, with proper labeling and patch panels. * Runs are certified and tested. * There’s a network closet with proper power, UPS, cooling, and rack layout. This gives you a controlled environment to start shaping your infrastructure standards. 5. Set expectations with leadership. Let the CEO know (politely) that bringing IT in-house isn’t just flipping a switch. It’s a staged process, assessing risk, building infrastructure, and training staff. That honesty buys you time and credibility when things inevitably need more than “a quick fix.” 6. Stack some small wins early. Fix visible pain points, slow Wi-Fi, printer issues, onboarding automation, etc., to build trust and momentum for bigger projects later. 7. Watch out for hidden landmines. You’ll probably uncover things like: * Expired SSL certs. * Backups that don’t actually restore. * “Temporary” admin accounts that are permanent. * Licenses registered to the MSP. * Inconsistent naming conventions or ancient GPOs still haunting the domain.

MAC OS, UNIX, and linux flavors, AS400

see always happens.