Today I found out that I wasn't making it to the next round of interviews for a sysadmin position at GitLab. However, this has fueled me into starting an active job search. However, I'm not quite sure how to start it.

I'm not planning on moving, so the position would have to be a remote one. I'm looking for an IT or a Development job, or some combination of the two.

Is LinkedIn actually a useful platform? I deleted my account when MS bought it, but I didn't feel like I got any benefit from it at the time.

I see quite a few remote jobs that I think will just accept US applicants but they don't clarify in the posting. Is it a better use of my time to mostly focus on remote jobs based in Canada? (unless I know that the company is international)

I also know that some jobs will accept remote workers if they seem like a good fit, but don't advertise the job as a remote position. Is it worth my time to be looking at and applying for jobs that might not even allow working remotely?

I've setup a proxy for decrypting TLS SMTP connections once for troubleshooting when I didn't have the private key for the SMTP server. Can't remember the name of the software I used now...

If you can focus on something you can use in your current job, it will definitely help your resume out because you can actually list professional experience with what you learned.

However, that route can make the transition to something else you want to do slower, if you can't use what you want to learn in in current job.

I was able to transition from IT into development, but I've been having a hard time really breaking away from the Microsoft world.

It would be equivalent with having to give write permissions for Users to a folder in Program Files. Basically a work around to make something work that's not completely engineered for non-privileged user use.

Sure, if the software was expecting to be run as an admin, but is being run as a regular user

tryton

@Dashrender said in Do I need to run AD if I install Server 2019?:

@scottalanmiller said in Do I need to run AD if I install Server 2019?:

@Dashrender said in Do I need to run AD if I install Server 2019?:

You're streaming into Windows 10, to a service that is not file or print. So how is it not violating the EULA?

Because that's like using youTube. YouTube is "steaming in", so is Netflix. That's a client action, and exactly what the OS is meant for.

The difference is that you sent the request to YouTube to send you data... are the cameras working the same? If the cameras are just broadcasting, and the client on the PC is asking for the stream.. then I agree with you.

Even if that's the case, there may be other features of the software that make it ask as a server. So then the user has to not use those features to stay within the EULA.

They have over 1000 users, but I have no idea on their setup, so maybe their complaints are mostly caused by their own setup, idk.

@DustinB3403 said in Using Skype For Business For Conference Calls:

To me that sounds like you have a s***** microphone if you take it up to a minute. I do not have that issue at all with any of my users and I have $170 people using it

I click the unmute button in the app and it freezes. Happens on both my home computer and my work computer.

@scottalanmiller said in Using Skype For Business For Conference Calls:

@flaxking said in Using Skype For Business For Conference Calls:

my biggest complaint is sometimes it takes a whole minute before it unmutes my mic.

What?!?!

Sometimes it's just enough of a delay to be annoying, but 1 minute can be detrimental.

Deploying a scheduled task can work really well for installing software, I would definitely recommend it over built-in GP msi deployment.

If you have a WSUS server, that works really well too. Not well enough to be the reason to maintain a WSUS server though.

I've worked on a project with a company that uses Skype for Business. They always complain about it, but my biggest complaint is sometimes it takes a whole minute before it unmutes my mic.

So the library GPO is linked somewhere above this user's OU and is using security filtering to apply to the library security group only?
Have Domain Computers been given read permission?

@David_CSG said in Opinions: Ansible vs. SaltStack:

For real road-warriors, I’ll leverage our RMM (Solarwinds), which is ok (I have to overcome shortcomings for the Mac with custom shell scripts, and shortcomings for Windows with custom powershell).

But I’d much rather leverage Ansible where possible.

Or you could use Salt to manage your in house and your road-warriors.
Though learning Ansible is probably a better career move (searching saltstack on stackoverflow jobs returns 7 results, ansible 106)

However, I believe that salt generally makes more sense for user computers than ansible

@David_CSG so what's your plan for ssh into laptops that are out and about?

@scottalanmiller said in Microsoft Office - Licensing Questions For 3 Scenarios:

@flaxking said in Microsoft Office - Licensing Questions For 3 Scenarios:

I think you must be missing what's going on here. This removes the requirement to integrate more directly with MS Office, instead relying on a separate library that is provided standalone from Office and thus allows saving to Excel. We've had zero issues with using this library, which is actually pretty uncommon for us.

The issue is flexibility. Using third party libraries, you can integrate with Excel or with anything else. Using the Office libraries, every user, in ever system, is bound by the limitations of the most problematic. It makes deployments more costly, and more complex.

That's true, it's the kind of self perpetuating lock-in that has served Microsoft so well. People use Excel, and they ask for saving to Excel spreadsheet, so we create the integration specially to allow Excel and not include ODF, then we help keep the industry locked into using Excel because that's all we support unless you want to just save to CSV.

As for the cost and complexity of deployments... that could be true, except that the installation of our main software is already so complex and costly that dealing with potentially installing this library is the easiest part. I think we probably only have one other developer who would be able to figure out how to install it. I've never heard of any client's IT that have been able to figure out how to install it (just calls from those who have tried), client services has to do literally every install.

@scottalanmiller said in Microsoft Office - Licensing Questions For 3 Scenarios:

@flaxking said in Microsoft Office - Licensing Questions For 3 Scenarios:

@Dashrender said in Microsoft Office - Licensing Questions For 3 Scenarios:

@flaxking said in Microsoft Office - Licensing Questions For 3 Scenarios:

@wrx7m said in Microsoft Office - Licensing Questions For 3 Scenarios:

@flaxking said in Microsoft Office - Licensing Questions For 3 Scenarios:

The ERP's dependency might be actually be ACE, and not Excel itself
https://www.microsoft.com/en-us/download/details.aspx?id=54920

Hmm. I don't know about that. We don't have access installed on the ERP server or any of the other systems.

It's a shared DLL, just installing Excel would install it on a system

That's some pretty crappy software using that engine if that's the case.

If they specifically want to create a feature which is an integration with Microsoft Excel, should they not use the tools provided by Microsoft to do so?

Absolutely not. That's considered one of the biggest, most amateur and/or "don't care about users" programming blunders. It's one of the most common red flags for bad software. Calling it the "tools provided by Microsoft" makes it sound logical, but when you describe it as "tools provided by Microsoft that require the end users to purchase, maintain, support, and constant fix integration with a tertiary product", then it is clear why only a total idiot or truly uncaring developer would do it. And as it is the second most well known "total screw up" for software development inclusions, there is absolutely no viable excuse for a programmer doing it (the most well known is hard coding to SQL Server for no reason.)

This is one of the standard "free for developers, screws the customer" tools that is used as the industry wide example of how lazy developers are lured into making bad software in order to forcible funnel money into a vendor. And it raises the actual cost of the end product, while generally making it flaky and unstable. We make a fortune supporting software that works this way because the MS Office products deregister or have problems all of the time and it is impossible for the software makers to support it. It literally makes their software "not work" reliably.

It's also one of the most common examples of what huge blunders happen when developers get to make decisions without the insight and oversight of operations teams. Because using these tools is easy for the devs, at the cost of totally screwing the end users and operations teams.

I think you must be missing what's going on here. This removes the requirement to integrate more directly with MS Office, instead relying on a separate library that is provided standalone from Office and thus allows saving to Excel. We've had zero issues with using this library, which is actually pretty uncommon for us.

We do support saving to CSV, but people specifically want excel, and believe it or not, they actually get confused by CSVs. I think this is thanks to how Excel implements CSVs, as well as poor spreadsheet training courses, as well as people who probably aren't qualified to touch a computer.

Honestly, our program is built on a series of poor choices, but I don't think this is really one of them.

@Dashrender said in Microsoft Office - Licensing Questions For 3 Scenarios:

@flaxking said in Microsoft Office - Licensing Questions For 3 Scenarios:

@wrx7m said in Microsoft Office - Licensing Questions For 3 Scenarios:

@flaxking said in Microsoft Office - Licensing Questions For 3 Scenarios:

The ERP's dependency might be actually be ACE, and not Excel itself
https://www.microsoft.com/en-us/download/details.aspx?id=54920

Hmm. I don't know about that. We don't have access installed on the ERP server or any of the other systems.

It's a shared DLL, just installing Excel would install it on a system

That's some pretty crappy software using that engine if that's the case.

If they specifically want to create a feature which is an integration with Microsoft Excel, should they not use the tools provided by Microsoft to do so?

@wrx7m said in Microsoft Office - Licensing Questions For 3 Scenarios:

@flaxking said in Microsoft Office - Licensing Questions For 3 Scenarios:

The ERP's dependency might be actually be ACE, and not Excel itself
https://www.microsoft.com/en-us/download/details.aspx?id=54920

Hmm. I don't know about that. We don't have access installed on the ERP server or any of the other systems.

It's a shared DLL, just installing Excel would install it on a system

The ERP's dependency might be actually be ACE, and not Excel itself
https://www.microsoft.com/en-us/download/details.aspx?id=54920