CommPulse

Hey r/azure , I wanted to share an interesting scenario we ran into during a live production deployment window this week involving Azure Data Factory and ARM templates. It served as a great refresher on Control vs. Data plane mechanics and hard Azure limits. (Anonymizing specific client/resource details) Blocker 1: The Control Plane Trap We were manually publishing our DEV Data Factory to generate the ARM templates in our adf_publish branch. The publish instantly failed with a LinkedAuthorizationFailed error regarding an Event Grid Subscription. The "Why": A developer had merged an Event-Based Trigger. While our ADF Managed Identity (Data Plane) had the permissions to run pipelines, a manual "Publish" action uses the engineer's physical Entra ID credentials (Control Plane). Because I lacked the EventGrid EventSubscription Contributor role on the target storage account, Azure Resource Manager blocked the entire publish. We simply reverted the trigger code to unblock the template generation. Blocker 2: The 256 Parameter Limit Once we reached the Azure DevOps Release pipeline, we noticed a Key Vault secret name for a Linked Service hadn't been parameterized (it was hardcoding a DEV/QA name). We jumped into arm-template-parameters-definition.json and applied a global wildcard to force parameterization of secretName for all Linked Services. The publish succeeded, but our DevOps pipeline crashed. The ARM template was completely invalid. Why? The 256 parameter limit. By applying the wildcard, ADF traversed our massive factory and generated over 300 parameters, instantly breaching the hard ARM architectural limit. The Strategic Workaround Fixing the 256 limit properly requires explicitly ignoring ("-") static variables across the whole factory to free up space. Doing that during a live deployment window was too high-risk. Instead, we reverted the parameterization fix. We took the hardcoded DEV/QA secret name the template was demanding, went into the PROD Key Vault, and created a secret with that exact non-production name - but populated it with the PROD credentials. The pipeline deployed, the Linked Service authenticated, and the deployment succeeded without breaching the parameter limit or requiring massive refactoring. Takeaways for me Just because your Managed Identity has access doesn't mean your manual deployment commands will. Know your execution planes. Be incredibly careful using wildcard parameterization in large ADF environments. Has anyone else hit the 256 ARM limit in ADF? How do you guys manage your arm-template-parameters-definition.json to keep the parameter footprint down? Would love to hear how others tackle parameter bloat or other similar issues in CI/CD! Generated using notebookllm submitted by /u/non_chalant_32 [link] [comments]

Hi everyone, I passed SC-900 on 27 July. I'm currently a Cybersecurity student, and I have one year left before graduating with my BS. My long-term goal is to become an Azure Cloud Security Architect. My current roadmap is: SC-900 → AZ-104 → SC-500 However, I don't have any corporate experience yet. My main question is: How can I prove my skills before getting my first job? I've heard people recommend solving real-world, business-centric cloud security scenarios, building GitHub projects, and creating a portfolio. But I'm not sure where to find these practical scenarios or how to approach them. Where can I get hands-on experience that actually reflects real-world Azure environments? Would the Azure Free Account with the $200 credit be enough to simulate enterprise-level scenarios? I understand that real corporate environments are much more complex, but I'm looking for the closest practical experience I can get as a student. Since SC-900 was mostly theoretical, my next target is AZ-104. However, my priority isn't collecting certifications,it's building real skills and having proof of work that I can show employers. I also have a question about Infrastructure as Code: I know Bicep is Azure-specific. Should I also learn Terraform? Is it worth pursuing the Terraform Associate (003/004) certification, or should I focus on developing practical Terraform skills instead of another certification? I'd really appreciate any advice from Azure professionals or cloud security engineers. If you were starting from scratch today with one year left before graduation, what would you focus on to maximize your chances of becoming an Azure Cloud Security Architect without wasting time on things that aren't valuable? Thanks in advance! submitted by /u/Junaid631 [link] [comments]

Has anyone tried their services? I'm interested in Iceland and Russia location.

Hey All, Just wanted to post a heads-up and document a recent practice by iON Cloud by Krypt regarding active, pre-paid annual plans. If you are running any legacy VPS with them, back up your data immediately and check your inbox. Service & Contract Background Plan: 1 vCPU / 2GB RAM / 40GB SSD / 1TB Bandwidth (ION-L09) Active Pre-paid Term: Dec 10, 2025 – Dec 09, 2026 (Fully paid up-front) Timeline of Events July 31, 2026 (1-Day Notice): Received an automated email stating that effective August 1, 2026, my legacy VPS will be forcibly migrated to their current "iON Pro 1" base plan. New Plan: 4 vCPU / 8GB RAM / 160GB SSD / 5TB Bandwidth New Rate: $40.00 / month (an 800% price increase for unneeded resources). My Response: I opened a billing ticket objecting to the mid-contract change, pointing out my active pre-paid contract valid through Dec 09, 2026, and requesting them to either honor the remaining term or provide a lower-tier plan. Billing's Response: Billing explicitly refused, stating: "As previously communicated, effective August 1, 2026, all affected legacy VPS services will be migrated to our current service plans... We are unable to maintain the legacy plan or pricing, and no alternative lower-tier plans are available." The "Store Credit" Trap: Since they refused to fulfill the contract, I agreed to cancellation and requested a pro-rated refund back to my original payment method for the remaining ~4.3 months. They replied: "As previously advised, we are unable to provide a refund to the original payment method. Any remaining prepaid balance will be applied to your account as account credit in accordance with our policy." Key Takeaways for the Community Zero Contract Integrity: Annual pre-paid agreements mean nothing to iON Cloud / Krypt. They will terminate active paid plans mid-term with less than 24–48 hours of advance notice. Forced Migrations: They push unnecessary 8x upgrades ($40/mo) on legacy users rather than offering reasonable lower tiers. Useless Refunds: Unilaterally terminating a contract on their end while refusing cash refunds—forcing non-refundable store credit on a provider you are leaving—is completely unacceptable. Consider this a public warning for anyone relying on iON Cloud / Krypt for long-term or pre-paid hosting.

I have been stuck in a 10 hour call today trying to update a horizon cert that expires in 48 hrs. Lucky I do have still have the old environment to update cert and test. (Old is horizon 7 main prod is horizon 8) In the old environment I'm getting after updating the cert I get the error "authentication cannot proceed domain name us invalid" but will work off domain auth through OKTA. I positive I followed the guides out there. I have 3 uags that point to the two connection servers that work for of prem connections. The two on prem servers have been set up the same way. Even understanding that new root and intermediate certs need to be sent out to local machines from GoDaddy was just managed from our workspace one My brain is fried and have look through so much documentation can someone here tell me I'm missing something so simple. submitted by /u/tj481138 [link] [comments]

submitted by /u/itspotterhead [link] [comments]

Happy System Administrator Day One of the titles I'm most proud to carry in my career is System Administrator. Today is dedicated to appreciating the people behind the scenes who keep businesses running every single day. Sysadmins and IT professionals work tirelessly to make sure technology just works. Your network is secure. Your computers are running. Your emails are flowing. Your printer isn't jammed (most of the time! 😄). You're protected from malware, phishing, and cyberattacks. Why? Because there's a dedicated SysAdmin, or an entire IT team, working behind the scenes to keep everything running smoothly. Working in an MSP, every day is different. Some days end with happy users after solving their issues. Some days... not so much. 😶 That's simply part of the job. When something stops working, it's easy to point fingers. But remember, when everything works perfectly 99% of the time, that deserves recognition too. Most issues are prevented long before they ever reach the end user because someone has been monitoring, maintaining, securing, and improving your environment. Today, take a moment to appreciate your System Administrator or IT team. Happy System Administrator Day to everyone keeping the world of IT running. submitted by /u/AppuniAkhil [link] [comments]

Went through all the hoops to have Dell survey and spec gear for my workloads, received the hardware recently and can’t even get it to support my idle CI runner workload without toppling over as the powerstore is quite literally the worst storage device ever made. They promised 86k iops and the powerstore bombs out at 10% of that due to IOSize. They really dropped the ball. Icing on the cake was the final f u today. They officially said they will not take back the appliance, comp local disk to just run those specific VMs , or even offer a discount on the local disk to work around the severe bottle neck. Had my var quote out the local disk 2 weeks ago before we proposed it as a solution and it can to 125k, they sent them a quote today for the request on this issue at double that. Do not buy a powerstore, do not buy Dell. They will refuse to support you after the fact and refuse to even attempt amends on the issues. I’d also like to add with the 3 node cluster this appliance was to support, we had a hardware issue 2 weeks after install and it took the server down for just shy of a month. I’d like to add I’m not even a tiny shop, I’ve spent around 1.8 million on Dell stuff this year alone. Jokes on them though as I had some discussions this week internally to basically refresh our entire network as things get on in age over the next 2 years. Other people make servers too. submitted by /u/Advanced-Reindeer508 [link] [comments]

Hi everyone, I'm currently learning Linux System Administration and building a RHEL-based Linux Application Server from scratch as part of my internship. One of the requirements is to implement a basic health check for the server. I'm trying to understand what experienced Linux administrators usually check before considering a server "healthy". So far, my checklist includes: CPU utilization / Load average Memory usage / Swap Disk usage and inode usage Filesystem & mount points Network interfaces IP / Gateway / DNS Internet connectivity Critical services (sshd, chronyd, firewalld, etc.) Time synchronization (NTP) SELinux status Firewall status System logs (journalctl) Package updates / Subscription status Questions: What are the minimum health checks every Linux server should have? What additional checks do you perform in production environments? Are there any important metrics or best practices that beginners usually overlook? Thanks! submitted by /u/Eds05 [link] [comments]

I hope everyone can help me out. I need this server, it costs 50 bucks. If you have any, please contact me. Thanks everyone

I bought a machine (server) from Nuyek on July 22nd. It's now been 7 days and the order status is still "Pending." I've submitted a support ticket, but they haven't responded either. What should I do?

Here's to another year of: - Being expected to diagnose problems via the sentence "it doesn't work." - Being blamed for issues caused by software you've never heard of. - Somehow knowing exactly what a user clicked, despite them insisting they "didn't do anything." - Explaining, yet again, that rebooting wasn't an insult, it was the solution. May your backups restore, your RAID stay green, and your first Friday night drink arrive before the first "quick question" Teams message. submitted by /u/BonezAU_ [link] [comments]

Anyone ever get deep into their IT career and you realize, damn I really made a career and a lot of money out of genuinely liking to fuck around with computers? Secondly, the fact that I have common sense has gotten me pretty far in this field. I don’t know if I could do any corp job besides IT. As much as I don’t like some things about it, it is pretty sweet. Especially when you are the one running the show at your company and no one else knows IT so no one can tell you shit. submitted by /u/saltyschnauzer27 [link] [comments]

Who here is going to allow cross tenant recall? Just wondering Edit: This is specially for cross tenant message recall, not Copilot recall. It goes live in Aug/Sep https://techcommunity.microsoft.com/blog/exchange/cross-tenant-message-recall-in-exchange-online/4535800 submitted by /u/anonymousITCoward [link] [comments]

Goal: The Data Encryption Key (DEK) should never be stored in our database—not even wrapped/encrypted. If someone gains read-only access to the DB, they shouldn't be able to decrypt the passwords. Current design: Admin uploads a CSV. A background worker generates a random 32-byte DEK for that upload request. Generate one-time passwords for each row. Encrypt each password with the DEK (AES-256-GCM) and store only the ciphertext in the DB. Store the DEK in Google Secret Manager as a new Secret Version . Store only the Secret Version reference (e.g. dek_secret_version ) in the DB. When the CSV is downloaded: Fetch the DEK from Secret Manager using the stored version. Decrypt the passwords. Generate and return the CSV. Destroy the Secret Version (crypto-shredding). Clear the encrypted password and version reference from the DB. We're considering using one Secret with many Versions , where each version represents a different upload request's DEK, rather than creating a new Secret for every upload. My questions are: Has anyone used Secret Manager this way (many versions representing independent DEKs rather than secret rotation)? Are there any quotas, performance issues, or operational pitfalls with having a large number of versions under a single Secret? Would you recommend a different GCP-native approach that still satisfies the requirement that the DEK is never persisted in the database , even in wrapped/encrypted form? Any concerns with the crypto-shredding workflow (destroying the Secret Version after a successful download or expiration)? I'd love to hear from anyone who's built something similar or has experience operating Secret Manager at scale. submitted by /u/Maximum-Scene2017 [link] [comments]

Normally I don't care much about limited promos but I didn't know vpshostingservice / @tpoll yet except for some basic info, which had created some interest, so I had a look at the offer. What "got" me and made me buy one (the cheapest) mainly was the really low price, 2 vCores of a supposedly fast processor, the recurring offer, and, albeit cautiously the unlimited traffic. Here's the results of > 30 benchmark runs over >= 24 hrs. Hint: buckle up! First, sysinfo, processor & memory Version 2.5.0a, (c) 2018+ jsg (->lowendtalk.com) Machine: amd64, Arch.: amd64, Model: Intel(R) Core(TM) i9-14900K OS, version: FreeBSD 14.4, Mem.: 1.989 GB CPU - Cores: 2, Family/Model/Stepping: 6/183/1 Cache: 32K/64K L1d/L1i, 4096K L2, 36M L3 Std. Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 cflsh mmx fxsr sse sse2 ss sse3 pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline aes xsave osxsave avx f16c rdrnd hypervisor Ext. Flags: fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb umip pku ospke syscall nx pdpe1gb rdtscp lm lahf_lm lzcnt AES? Yes Nested Virt.? Yes HW RNG? Yes ProcMem SC [MB/s]: avg 505.0 - min 186.9 (37.0 %), max 820.2 (162.4 %) ProcMem MA [MB/s]: avg 1366.8 - min 1210.0 (88.5 %), max 1520.0 (111.2 %) ProcMem MB [MB/s]: avg 1429.1 - min 1260.0 (88.2 %), max 1550.0 (108.5 %) ProcMem AES [MB/s]: avg 2651.8 - min 2577.3 (97.2 %), max 2717.4 (102.5 %) ProcMem RSA [kp/s]: avg 198.8 - min 186.9 (94.0 %), max 207.8 (104.5 %) WUT? 500+ MB/s single-core avg? And well matched and high multi-core results. Plus over 2500 MB/s AES and pretty much double the RSA keypairs per second I usually see on fast processors! This VPS clearly has the fastest processor I benchmarked so far! And for about $20/year! Frankly with that kind of processing power that box could have a boring old-style SSD and mediocre connectivity and I'd still be happy and call it a good deal. But no, wait and see ... --- Disk 4 KB - Buffered --- Write seq. [MB/s]: avg 7.53 - min 6.23 (82.7%), max 8.57 (113.8%) Write rnd. [MB/s]: avg 7.04 - min 6.33 (89.9%), max 8.05 (114.3%) Read seq. [MB/s]: avg 16.02 - min 13.08 (81.7%), max 19.84 (123.9%) Read rnd. [MB/s]: avg 14.91 - min 12.59 (84.4%), max 18.70 (125.4%) --- Disk 4 KB - Sync/Direct --- Write seq. [MB/s]: avg 7.13 - min 6.32 (88.6%), max 8.12 (113.9%) Write rnd. [MB/s]: avg 6.83 - min 5.88 (86.1%), max 7.70 (112.7%) Read seq. [MB/s]: avg 15.54 - min 13.30 (85.6%), max 19.69 (126.7%) Read rnd. [MB/s]: avg 14.65 - min 12.74 (87.0%), max 18.05 (123.2%) --- Disk 64 KB - Buffered --- Write seq. [MB/s]: avg 78.53 - min 71.98 (91.7%), max 111.55 (142.0%) Write rnd. [MB/s]: avg 72.54 - min 67.60 (93.2%), max 78.24 (107.9%) Read seq. [MB/s]: avg 2762.90 - min 2507.97 (90.8%), max 2973.97 (107.6%) Read rnd. [MB/s]: avg 205.07 - min 175.73 (85.7%), max 224.75 (109.6%) --- Disk 64 KB - Sync/Direct --- Write seq. [MB/s]: avg 20.34 - min 17.73 (87.2%), max 22.52 (110.7%) Write rnd. [MB/s]: avg 13.20 - min 10.25 (77.6%), max 15.30 (115.9%) Read seq. [MB/s]: avg 2757.39 - min 2514.95 (91.2%), max 2951.18 (107.0%) Read rnd. [MB/s]: avg 201.74 - min 168.27 (83.4%), max 226.61 (112.3%) --- Disk 1 MB - Buffered --- Write seq. [MB/s]: avg 351.89 - min 313.92 (89.2%), max 367.91 (104.6%) Write rnd. [MB/s]: avg 417.48 - min 382.93 (91.7%), max 447.95 (107.3%) Read seq. [MB/s]: avg 3013.75 - min 2914.00 (96.7%), max 3186.12 (105.7%) Read rnd. [MB/s]: avg 887.17 - min 833.02 (93.9%), max 923.27 (104.1%) --- Disk 1 MB - Sync/Direct --- Write seq. [MB/s]: avg 113.20 - min 73.32 (64.8%), max 120.88 (106.8%) Write rnd. [MB/s]: avg 103.21 - min 92.82 (89.9%), max 115.96 (112.4%) Read seq. [MB/s]: avg 3127.43 - min 2981.84 (95.3%), max 3324.28 (106.3%) Read rnd. [MB/s]: avg 896.91 - min 827.43 (92.3%), max 956.37 (106.6%) --- Disk IOps (Sync/Direct) --- Write seq. [MB/s]: avg 47.18 - min 46.52 (98.6%), max 47.60 (100.9%) IOps : avg 12077.15 - min 11908.60 (98.6%), max 12186.73 (100.9%) Almost 50 MB/s and 12000 IOps in 4k/4t mode is a very good result by itself, but look at the super-tight spread! which translates to "this NVMe performs consistently good "! But to be honest I was prepared to get, uhm, ... only mediocre connectivity because AFAIK vpshostingservice runs on ColoCrossing infrastructure which I (falsely I guess) assumed to be HE and/or Cogent (which I've learned to strongly dislike) linked - but with that processor and disk performance I didn't even care and was fully prepared to like my new little server anyway ... So, let's see ... --- Europe --- NO OSL mirror.terrahost.no [F: 0] DL [Mb/s]: avg 110.9 - min 98.8 (89.1%), max 115.4 (104.0%) Ping [ms]: avg 97.7 - min 97.5 (99.8%), max 97.8 (100.1%) Web ping [ms]: avg 137.7 - min 97.5 (70.8%), max 200.9 (145.9%) UK LON lon.speedtest.clouvider.net [F: 0] DL [Mb/s]: avg 131.5 - min 115.9 (88.1%), max 140.9 (107.1%) Ping [ms]: avg 87.0 - min 86.3 (99.2%), max 87.9 (101.0%) Web ping [ms]: avg 89.0 - min 86.3 (97.0%), max 105.7 (118.8%) NL AMS nl.mirrors.clouvider.net [F: 0] DL [Mb/s]: avg 125.3 - min 109.9 (87.7%), max 129.3 (103.2%) Ping [ms]: avg 87.4 - min 86.8 (99.3%), max 88.6 (101.3%) Web ping [ms]: avg 89.5 - min 86.8 (96.9%), max 97.1 (108.4%) DE FRA fra.lg.core-backbone.com [F: 0] DL [Mb/s]: avg 124.8 - min 123.9 (99.3%), max 125.8 (100.8%) Ping [ms]: avg 90.7 - min 90.3 (99.6%), max 93.4 (103.0%) Web ping [ms]: avg 90.8 - min 90.4 (99.6%), max 93.4 (102.9%) FR PAR mirror.in2p3.fr [F: 0] DL [Mb/s]: avg 113.4 - min 107.8 (95.1%), max 120.0 (105.9%) Ping [ms]: avg 94.6 - min 94.4 (99.8%), max 95.2 (100.6%) Web ping [ms]: avg 129.6 - min 103.7 (80.0%), max 414.4 (319.7%) CH GEN pkg.adfinis-on-exoscale.ch [F: 0] DL [Mb/s]: avg 122.5 - min 116.4 (95.0%), max 130.4 (106.4%) Ping [ms]: avg 96.0 - min 95.7 (99.7%), max 96.1 (100.1%) Web ping [ms]: avg 103.6 - min 95.9 (92.6%), max 120.3 (116.2%) ES MAD mirror.raiolanetworks.com [F: 0] DL [Mb/s]: avg 121.8 - min 118.6 (97.4%), max 123.5 (101.4%) Ping [ms]: avg 92.4 - min 92.1 (99.6%), max 96.0 (103.9%) Web ping [ms]: avg 94.1 - min 92.3 (98.1%), max 96.2 (102.3%) RO BUC mirrors.hosterion.ro [F: 0] DL [Mb/s]: avg 90.7 - min 84.5 (93.2%), max 98.0 (108.1%) Ping [ms]: avg 119.0 - min 116.1 (97.6%), max 122.0 (102.5%) Web ping [ms]: avg 124.0 - min 116.3 (93.8%), max 133.6 (107.8%) RU MOS mirror.yandex.ru [F: 0] DL [Mb/s]: avg 75.2 - min 70.2 (93.4%), max 80.2 (106.6%) Ping [ms]: avg 144.0 - min 0.0 (0.0%), max 150.0 (104.2%) Web ping [ms]: avg 155.9 - min 0.0 (0.0%), max 337.3 (216.4%) RU MOS speedtest.hostkey.ru [F: 20] DL [Mb/s]: avg 50.6 - min 0.0 (0.0%), max 97.5 (192.6%) Ping [ms]: avg 117.1 - min 116.7 (99.7%), max 119.3 (101.9%) Web ping [ms]: avg 124.0 - min 116.8 (94.2%), max 150.7 (121.5%) --- Asia/Oceania --- RU SIB mirror.truenetwork.ru [F: 0] DL [Mb/s]: avg 63.5 - min 22.2 (34.9%), max 71.0 (111.9%) Ping [ms]: avg 167.6 - min 165.1 (98.5%), max 172.7 (103.1%) Web ping [ms]: avg 182.2 - min 165.1 (90.6%), max 231.2 (126.9%) IN MUM mirrors.piconets.webwerks.in [F: 0] DL [Mb/s]: avg 46.3 - min 41.3 (89.1%), max 49.4 (106.7%) Ping [ms]: avg 244.5 - min 163.6 (66.9%), max 246.7 (100.9%) Web ping [ms]: avg 250.4 - min 246.0 (98.2%), max 272.6 (108.8%) SG SGP mirror.sg.gs [F: 0] DL [Mb/s]: avg 47.4 - min 40.9 (86.3%), max 51.5 (108.6%) Ping [ms]: avg 225.3 - min 217.9 (96.7%), max 235.8 (104.6%) Web ping [ms]: avg 238.9 - min 223.7 (93.6%), max 260.4 (109.0%) CN HKG mirrors.xtom.hk [F: 0] DL [Mb/s]: avg 59.0 - min 56.8 (96.3%), max 59.9 (101.5%) Ping [ms]: avg 191.0 - min 190.7 (99.8%), max 191.3 (100.1%) Web ping [ms]: avg 195.4 - min 190.9 (97.7%), max 304.2 (155.7%) CN BEJ mirrors.bfsu.edu.cn [F: 0] DL [Mb/s]: avg 43.1 - min 35.6 (82.8%), max 51.7 (120.1%) Ping [ms]: avg 240.1 - min 0.0 (0.0%), max 283.1 (117.9%) Web ping [ms]: avg 252.0 - min 0.0 (0.0%), max 300.4 (119.2%) JP TOK ftp.udx.icscoe.jp [F: 0] DL [Mb/s]: avg 65.1 - min 33.7 (51.7%), max 75.8 (116.4%) Ping [ms]: avg 153.6 - min 153.4 (99.8%), max 154.4 (100.5%) Web ping [ms]: avg 164.1 - min 153.5 (93.5%), max 176.9 (107.8%) AU SYD mirrors.xtom.au [F: 0] DL [Mb/s]: avg 60.3 - min 58.4 (96.8%), max 61.6 (102.1%) Ping [ms]: avg 191.2 - min 190.9 (99.9%), max 191.3 (100.1%) Web ping [ms]: avg 251.5 - min 226.5 (90.1%), max 330.8 (131.5%) --- Africa --- ZA WEC archlinux.za.mirror.allworldit.com [F: 0] DL [Mb/s]: avg 45.7 - min 25.9 (56.7%), max 50.4 (110.2%) Ping [ms]: avg 227.4 - min 223.7 (98.4%), max 245.8 (108.1%) Web ping [ms]: avg 242.9 - min 224.2 (92.3%), max 274.4 (113.0%) --- Americas --- CA MTL speedtest.mtl2.ca.leaseweb.net [F: 0] DL [Mb/s]: avg 432.5 - min 425.4 (98.4%), max 434.7 (100.5%) Ping [ms]: avg 11.9 - min 11.7 (98.0%), max 12.7 (106.4%) Web ping [ms]: avg 12.0 - min 11.7 (97.2%), max 12.7 (105.5%) US NYC nyc.mirrors.clouvider.net [F: 0] DL [Mb/s]: avg 430.1 - min 419.0 (97.4%), max 433.9 (100.9%) Ping [ms]: avg 12.0 - min 11.7 (97.7%), max 12.2 (101.9%) Web ping [ms]: avg 12.1 - min 11.8 (97.2%), max 12.6 (103.8%) US ASH ash.speedtest.clouvider.net [F: 0] DL [Mb/s]: avg 421.4 - min 408.1 (96.8%), max 423.2 (100.4%) Ping [ms]: avg 17.5 - min 17.2 (98.0%), max 19.8 (112.9%) Web ping [ms]: avg 18.0 - min 17.2 (95.3%), max 24.6 (136.3%) US WDC speedtest.wdc2.us.leaseweb.net [F: 0] DL [Mb/s]: avg 310.7 - min 84.7 (27.3%), max 423.0 (136.1%) Ping [ms]: avg 17.7 - min 17.4 (98.4%), max 17.9 (101.2%) Web ping [ms]: avg 17.9 - min 17.5 (98.0%), max 18.8 (105.3%) US PIB mirror.pit.teraswitch.com [F: 0] DL [Mb/s]: avg 374.9 - min 223.5 (59.6%), max 409.7 (109.3%) Ping [ms]: avg 23.2 - min 23.0 (99.3%), max 23.4 (101.0%) Web ping [ms]: avg 25.6 - min 23.1 (90.3%), max 28.5 (111.3%) US MIA speedtest.mia11.us.leaseweb.net [F: 0] DL [Mb/s]: avg 243.8 - min 162.7 (66.7%), max 265.4 (108.9%) Ping [ms]: avg 45.9 - min 45.7 (99.6%), max 46.1 (100.5%) Web ping [ms]: avg 45.9 - min 45.7 (99.5%), max 46.5 (101.2%) US CHI speedtest.chi11.us.leaseweb.net [F: 0] DL [Mb/s]: avg 430.7 - min 427.7 (99.3%), max 432.6 (100.4%) Ping [ms]: avg 12.5 - min 12.3 (98.3%), max 12.6 (100.7%) Web ping [ms]: avg 12.6 - min 12.3 (97.9%), max 12.8 (101.9%) US ATL atl.speedtest.clouvider.net [F: 0] DL [Mb/s]: avg 369.8 - min 332.4 (89.9%), max 400.7 (108.4%) Ping [ms]: avg 30.2 - min 26.7 (88.4%), max 33.1 (109.6%) Web ping [ms]: avg 32.7 - min 26.7 (81.7%), max 47.6 (145.6%) US PHO speedtest.phx1.us.leaseweb.net [F: 0] DL [Mb/s]: avg 202.6 - min 175.0 (86.4%), max 215.0 (106.1%) Ping [ms]: avg 58.2 - min 0.0 (0.0%), max 70.8 (121.7%) Web ping [ms]: avg 58.2 - min 0.0 (0.0%), max 70.8 (121.7%) US PTL mirrors.cat.pdx.edu [F: 0] DL [Mb/s]: avg 169.7 - min 167.2 (98.6%), max 171.1 (100.9%) Ping [ms]: avg 66.5 - min 66.0 (99.3%), max 70.8 (106.5%) Web ping [ms]: avg 70.8 - min 67.2 (95.0%), max 81.4 (115.0%) US LAX mirror.alma.lax1.serverforge.org [F: 0] DL [Mb/s]: avg 169.9 - min 111.2 (65.4%), max 199.8 (117.6%) Ping [ms]: avg 67.4 - min 56.5 (83.8%), max 78.2 (116.0%) Web ping [ms]: avg 72.7 - min 57.0 (78.4%), max 91.6 (126.0%) US SJO mirrors.xtom.us [F: 0] DL [Mb/s]: avg 139.0 - min 103.7 (74.6%), max 149.3 (107.4%) Ping [ms]: avg 78.6 - min 75.4 (96.0%), max 93.0 (118.4%) Web ping [ms]: avg 81.4 - min 75.6 (92.9%), max 104.7 (128.7%) US SEA speedtest.sea11.us.leaseweb.net [F: 0] DL [Mb/s]: avg 198.9 - min 168.0 (84.5%), max 210.5 (105.8%) Ping [ms]: avg 57.5 - min 57.4 (99.9%), max 57.6 (100.3%) Web ping [ms]: avg 57.6 - min 57.4 (99.7%), max 58.8 (102.1%) BR SPA mirrors.ic.unicamp.br [F: 0] DL [Mb/s]: avg 65.4 - min 56.2 (86.0%), max 74.4 (113.8%) Ping [ms]: avg 177.8 - min 152.8 (85.9%), max 201.1 (113.1%) Web ping [ms]: avg 177.8 - min 152.8 (85.9%), max 201.1 (113.1%) BR CUR archlinux.c3sl.ufpr.br [F: 0] DL [Mb/s]: avg 63.5 - min 55.3 (87.2%), max 72.2 (113.7%) Ping [ms]: avg 181.9 - min 159.7 (87.8%), max 204.1 (112.2%) Web ping [ms]: avg 181.9 - min 159.7 (87.8%), max 204.1 (112.2%) CL SAN mirror.anquan.cl [F: 4] DL [Mb/s]: avg 40.8 - min 0.0 (0.0%), max 83.5 (204.6%) Ping [ms]: avg 144.3 - min 136.2 (94.4%), max 155.1 (107.5%) Web ping [ms]: avg 178.1 - min 141.7 (79.5%), max 255.0 (143.1%) CL SAN elmirror.cl [F: 2] DL [Mb/s]: avg 63.7 - min 0.0 (0.0%), max 82.3 (129.3%) Ping [ms]: avg 142.6 - min 138.5 (97.1%), max 159.1 (111.6%) Web ping [ms]: avg 150.9 - min 138.6 (91.8%), max 171.3 (113.5%) Europe - OK, UK, Lon, NL, Ams, and DE, Fra showing good results isn't a surprise, but NO, Osl, and FR, Par, and even CH and ES showing results well above 100 Mb/s is a very nice start indeed! Asia / Oceania - well, I'd call those results decent for a VPS in Buffalo, I guess. Nothing to write home about but neither a reason to complain. Maybe from an american perspective the verdict would be more positive. Africa - let's politely skip that Americas - 400+ Mb/s in Murrica, East-Coast? OK, I'm very Europe-centric and relatively ignorant/clueless wrt Murrica but 400+ Mb/s? I don't think I ever saw results like that. OK, about 250 Mb/s is another level but actually not bad for Miami. Chicago reaches 400+ Mb/s again and then the numbers get lower towards the West, ending with very respectable (almost) 200 Mb/s in the North and still really good 170-ish Mb/s in the South. Finally the two Brazil targets as well as at least one Chile target show quite respectable results too. Really nice. The secret sauce? Almost no HE or Cogent (except within Murrica) and plenty twelve99 and other top carriers! Very well done! @tpoll , what are you doing with us? Didn't they inform you that 20 bucks per year buys maybe nice but not really good VPS on LET (if one is lucky)? And then comes tpoll and gives us a really, really nice, highly performant, and well rounded VPS for less than two bucks per month? Didn't it cross your mind that a reviewer is used to have something to complain about, at least some detail? How reckless and ignorant of you to throw such a performant and balanced VPS without even a single issue to complain about at us and dirt-cheap at that?! Here is my revenge: highly recommended! One of the best deals I ever tested.

I’ve realized that even after I finish work, my brain keeps thinking about it. I replay conversations, think about problems I didn’t solve, plan tomorrow’s tasks, or imagine different scenarios. Sometimes it feels like I’m still working hours after I’ve logged off. I’m curious: how do you mentally switch off? Do you have any routines, hobbies, or habits that help you leave work at work? Or did it simply get easier with experience? I’d love to hear what actually works for you. submitted by /u/Natural_Pool_5493 [link] [comments]

I would never use them, but in taking over a project, I was trying to gain access to what was once a Dotster account used for managing DNS on some domains. Seeing that Network Solutions acquired Dotster, I assume the account would be held with them. Tried calling them, like I have all the other service providers I needed to gain access to, and work on account recovery. Every phone number they publish on their website just plays a recorded message that loops (seemingly infinitely), "Sorry, and error occurred. Please try your call again." Is this a temporary outage, or do they just like to post numbers on their website that don't work? submitted by /u/exitof99 [link] [comments]

Hello, We have an apps server that is a remote desktop server for a few old apps. They want to use licensing monthly from MS, they don't want to buy the licenses. I've set up the RDP services but I'm not sure what to select in the last part for activate e.g open license, select license, enterprise... submitted by /u/Deep-Egg-6167 [link] [comments]

submitted by /u/MadDawgThaKing [link] [comments]