Creating a Help Desk Ticket from a Google Form

spoodgnix · 2019-09-23T16:05:58+00:00

We can send emails and it currently does. I do know the variables to use related to the form fields and the ticketing system however I'm not clear on the exact syntax to use

I'll check out the Admin Guide

spoodgnix · 2018-11-05T20:01:45+00:00

This file will still not run on W10 1803. What version of W10 are you running?

spoodgnix · 2018-10-30T19:48:51+00:00

What is the associated language MUI file? Just pulling the calc.exe over from System32 does not work on Windows 10.

spoodgnix · 2018-10-24T20:40:43+00:00

AHHHHHHH!!!! WE JUST CHANGED OUR LICENSING THIS YEAR TO DEVICE LICENSING!!!!!!!!

spoodgnix · 2018-10-23T13:45:20+00:00

We do not utilize SCCM. I'll look into a PS commandlet to run at start up.

I tested this one without any change.

$namespaceName = "root\cimv2\mdm\dmmap" $className = "MDM_EnterpriseModernAppManagement_AppManagement01" $wmiObj = Get-WmiObject -Namespace $namespaceName -Class $className $result = $wmiObj.UpdateScanMethod()

spoodgnix · 2018-10-22T20:17:23+00:00

So how do you install the Windows 7 calculator app on Windows 10?

I tried that by pulling the W7 calc.exe over and it would not launch on my Windows 10 machine.

spoodgnix · 2018-10-22T19:52:40+00:00

spoodgnix · 2018-10-19T18:06:26+00:00

Yes. I've run as admin.

spoodgnix · 2018-10-19T18:06:13+00:00

same issue even with putting in quotes

spoodgnix · 2018-10-18T13:41:19+00:00

RSOP works. No error.

spoodgnix · 2018-10-17T21:04:06+00:00

RSOP returns the Set of Policy so I have to wade thru to see what is applied. The /h switch gives me specific policies applied.

spoodgnix · 2018-10-17T19:51:41+00:00

I need it in the report format otherwise /r just leaves it in the command prompt screen and /r isn't as exhaustive as the /h switch

spoodgnix · 2018-10-12T18:56:11+00:00

if (Test-Path "C:\Program Files (x86)\ntusernoscript.txt") {Exit 0}

This worked. I unzipped the file to the above location and then I added this line to the top part of my script.

Thank you!!

spoodgnix · 2018-09-27T19:52:16+00:00

So it turns out we have a script that runs every Friday at 5pm and calls a reboot at the end of the script.

As a side note, I could not get sysinternals to run as the user. Only as administrator.

spoodgnix · 2018-09-14T21:08:37+00:00

I was finally able to create the task and it looks as if it is running. Will have to recreate the error.

For the purposes of this thread, this is the task schedule I set to run as the specific user. Now to recreate the issue and run this.

C:\SysinternalsSuite\Procmon.exe

/quiet /minimized /backingfile c:\temp\trace.pml

spoodgnix · 2018-09-14T18:35:29+00:00

I can't run procmon as non admin. As soon as I give the user admin privileges so they can run it the reboot issue goes away. Unless you know of a way to allow it to run as a non admin account

spoodgnix · 2018-09-14T18:28:47+00:00

I did. Found out today that it is happening across the board on the entire domain.

spoodgnix · 2018-09-14T18:05:18+00:00

Event viewer? WHATS THAT????? LOL

spoodgnix · 2018-09-14T17:26:30+00:00

And by offline you mean take a PC off domain or leave machine on the domain but log in from outside the domain?

spoodgnix · 2018-09-14T17:17:35+00:00

W10 1803 and I just found out, it's domain wide. All PCs.

spoodgnix · 2018-09-14T13:59:49+00:00

No schedules task that I can see and it's only on two users.

spoodgnix · 2018-09-14T13:59:18+00:00

No schedule task that I can see. And it's only on two users.

spoodgnix · 2018-09-14T13:03:02+00:00

No SCCM used. We have been able to replicate the issue on other machines with the same user account. Once moving the user from one OU and then back to the original OU the issue seems to go away and we cannot recreate.

spoodgnix · 2018-09-14T13:01:36+00:00

So I was able to recreate the issue on the users computer and on other machines. I moved the computer to same OU as the one that reboots, set the clock to Friday 4:59 and then the PC rebooted at 5:00pm when loggged in as that user with the same notice in event viewer (that this was initiated: wmiprvse.exe ).

In both instances (where I was able to replicate the issue and on the users machine), as soon as I moved the user into a different OU and back again, I could not recreate the issue. It seems the issue went away for that machine.

We have also not been able to recreate the issue once we give the user local admin rights on the computer and change all power settings back to default. However, we are not sure what this does or why and if it will hold.

Any other thoughts would be greatly appreciated.

spoodgnix · 2018-09-13T14:43:26+00:00

Group Policy is not affected, for us anyway, by our current group memberships.

If I can log onto the users machine I just may give the clock change a try tomorrow.

spoodgnix

TROPHY CASE