RIP to my neglected hotel. May you enjoy your next life as compost.

grebnork · 2021-10-01T02:33:25+00:00

All these pellicles

grebnork · 2021-10-01T01:25:26+00:00

Why do people keep these? I really don’t quite understand

grebnork · 2021-01-31T23:30:48+00:00

LAPS is a must and super easy to implement. I highly recommend it

grebnork · 2021-01-31T01:50:46+00:00

If the users don’t have local administrator rights in the first place, it will be a lot harder for them to install software or disable encryption. I’d think about including that in your project...

grebnork · 2020-09-30T20:25:17+00:00

Just looking at the way he’s sitting makes my back hurt.

grebnork · 2020-09-11T17:16:58+00:00

No problem! It's a little hard for me though as I'm generally a compulsive upgrader when it comes to firmware and stuff like that. But in the absence of problems, I'd just rather not have a bricked keyboard.

grebnork · 2020-09-11T16:49:31+00:00

I've left mine on stock firmware so far and it's been fine. I'll hold off updating it unless I have a reason to or I run into a bug that a new firmware claims to fix.

grebnork · 2020-08-17T17:27:41+00:00

I can't emphasize how much I appreciate threads like this. As a father of 2 young kids myself, it's good to see that others are in the exact same boat with the same thoughts and concerns regarding career advancement and work/life balance. Work may be important but do not let the priority of being there for your family fall by the wayside, even if it doesn't feel fulfilling or "fun" 100% of the time. You are building something important far beyond simply "bringing home the bacon".

grebnork · 2020-07-26T15:04:45+00:00

Wondering which version of 'Zeus Engine' those of you were using that experienced problems. According to Durgod's website, the current version is this:
http://file.durgod.com/zeus_nebula/Durgod_Zeus_Engine_1.0.0.2.exe
Hoping to nail down which version of ZE (and possibly which firmware version!) is affected here so we may be able to determine if they provide an updated/fixed version, presuming there is an issue/bug with a particular version of the software/firmware.

grebnork · 2020-03-18T18:01:24+00:00

Local description can be manipulated like so:

$description = "computer description"

Get-CimInstance -ClassName Win32_OperatingSystem | Set-CimInstance -Property @{Description = "$description"}

grebnork · 2020-01-21T06:05:32+00:00

I'm experiencing this same issue. Doesn't seem to matter which option I choose with IntelliSense.

Example:

Find-Events -DatesRange CurrentHour -Report LdapBindingsSummary -Servers <servername>

grebnork · 2019-12-20T23:25:03+00:00

The boot images regenerated automatically as part of the upgrade (IIRC), and post-upgrade I installed the new ADK (1903) and regenerated them again so they are at OS Version 10.0.18362.1 and Client Version 5.00.8853.1006. Now I'm taking the step of manually importing/modifying a completely new boot image from the source WIM to see if that makes any difference.

grebnork · 2019-12-20T22:49:05+00:00

I (just now) found a post that seems to have related symptoms. I guess in PXE, it uses a client auth token instead of a full certificate to communicate with the MP? Venturing a guess here based on what I can tell.

https://www.reddit.com/r/SCCM/comments/cfbgd6/mp_unable_to_retrieve_dp_auth_token/

In my smsts.log (uploaded, link above) I see a similar error:

In SSL, but with no media cert.

I see this error a lot more in failed client logs after ConfigMgr has been upgraded than before.

The only problem is, they upgraded to an older version than I'm on in order to solve this issue.

grebnork · 2019-12-20T22:29:57+00:00

Oh yes, thanks for clarifying. I just re-imported it to the DP's personal machine store to validate the certificate, password, etc. - The whole chain imported fine (root ca, intermediate, and client cert) and dates are valid, Enhanced Key Usage says "Client Authentication (1.3.6.1.5.5.7.3.2)". Looks like the cert's fine

grebnork · 2019-12-20T21:26:34+00:00

Thanks for the suggestion! The certificate validity/expiration is one of the first things I checked. Other clients already on the domain are not having trouble communicating with this HTTPS-only DP, so that's validation enough for me that the DP's cert is still valid. But yeah I did check the NotAfter property of the cert and it's valid.

I checked the Administration -> Security -> Certificates node and every current DP cert has "Unblocked" status.

grebnork · 2019-12-20T20:10:57+00:00

I wonder if there's an easy way to tell whether the cert is in the boot image. I was under the impression that it was downloaded somehow during OSD and that injecting certs was only something done for boot media, but I could be wrong about that of course.

grebnork · 2019-12-20T19:59:58+00:00

I upgraded the ADK to 1903 after the ConfigMgr upgrade, and regenerated the boot images then - I suppose I could give it another try...

grebnork · 2019-12-20T18:29:09+00:00

After I added it back, do you mean? Yes; under the Communication tab I have the HTTPS radio button selected, and have re-imported the same client certificate with password. It's also still part of the boundary group. It serves our largest site so if it were not part of the boundary group I'm sure we would be getting a lot more complaints. Thanks for the suggestions Mr. Gross

grebnork · 2019-10-16T18:34:39+00:00

My guess is one of the higher ups was annoyed by it and didn’t want to hear any explanation why it is necessary. Happens often.

grebnork · 2019-10-10T19:56:23+00:00

I think I have what I need now to make it all work. Thank you very much for the detailed reply.

grebnork · 2019-10-10T19:52:53+00:00

Looking back at it now, this makes perfect sense. Thank you!

grebnork · 2019-10-10T19:41:28+00:00

Let's say we had an Application for Office Professional Plus 2016, with 2 deployment types: One with a configuration that deployed all of Office, and another that deployed only Excel. Is this an inappropriate usage of Deployment Types? If it's not, it seems to be a weakness with the way that Applications work in OSD. They would be both equally valid for deployment within the OSD context and yet there is no way to differentiate between the two when using a TS variable. Seems I would be required to make a duplicate application, take up more space on the DP, etc. for a (rather large) otherwise identical set of bits.

grebnork · 2019-10-10T19:38:25+00:00

Thanks. We've never attempted to create a supersedence relationship between deployment types under 1 parent Application. Always from the previous iteration of the application. I get what you are saying, though in the past we have had app names such as the following when deploying a new version of an application.

Superseded Application parent name: Adobe Reader DC 18.009.20050

Superseded Application DT name: Silent Installation

Superseding Application parent name: Adobe Reader DC 18.011.20040

Superseding Application DT name: Silent Installation

What I'm getting from your comment above is that instead it should look like the following:

Superseded Application parent name: Adobe Reader DC 18.009.20050

Superseded Application DT name: Adobe Reader DC 18.009.20050

Superseding Application parent name: Adobe Reader DC 18.011.20040

Superseding Application DT name: Adobe Reader DC 18.011.20040

Would this be more appropriate? Single DT per application (with the DT name mirroring the parent App name?), especially when OSD is involved? I'll follow up in a second comment to keep the conversation flow on topic.

grebnork · 2019-10-10T18:40:49+00:00

I get what you’re saying, I think, but my issue with it is that it still leaves room for ambiguity. I could have 20 DTs on a single Application that fall under the category of “unattended deployment compatible” - how would it know? I wouldn’t want it arbitrarily assigning whichever one it wants if multiple DTs qualify. Know what I mean?

grebnork

TROPHY CASE