How To Query Active Directory For Object Group Memberships…

2017-07-27T00:01:04+00:00 February 6th, 2013|Uncategorized|

Not too long ago, I was working with a colleague who was doing a lot of user management and provisioning, and needed to be able to look up the group membership of a user (or a computer) without being too complex or having to memorize anything.  So I installed RSAT on the computer, and made a little batch file that he could run that will take the username (as samAccountName) and dump out the direct or inherited memberships.  Easy as pie.

And as I often do, I thought I’d put up a little blog post detailing the mechanics and concepts of the script.  Of course, we’ve touched on some of these concepts before in this blog, but never in this direct of a way.  So without further ado…

How to Check Group Memberships from the User or Computer Perspective

If you already have the userID/samAccountName, then you can check *user* DIRECT group memberships like this example:

dsquery user -samid "JPavlov" |dsget user -memberof

…and to check *user* INHERITED group memberships, use the expand flag:

dsquery user -samid "JPavlov" |dsget user -memberof -expand


Similarly, you can check *computer* DIRECT group memberships like this example:

dsquery computer -name "CTS004895" |dsget computer -memberof

…and to check *computer* INHERITED group memberships:

dsquery computer -name "CTS004895" |dsget computer -memberof -expand


How to Check Groups Memberships from the Group Perspective

Of course, I just can’t leave it there.  What if you want to approach it from the other direction?  For instance, if you have a group name (or a prefix if you have a naming convention), and you want to get a membership list of that group?  It’s still doable.  And while I’m at it, I thought I’d sprinkle in a little bit of PowerShell, and still use dsquery to get the job done, as in the following example:

$StartingContext = "OU=Groups,OU=Location,DC=Coretek,DC=local"
$GroupPrefix = "CTS FH "
$GroupList = dsquery * $StartingContext -limit 9000 -filter "(&(objectClass=Group)(name=$GroupPrefix*))" -attr samAccountName,member

…and this works, but… unfortunately, the output is horrible because the dsquery output is ugly.  But, if you happen to already have a list of group names (as in my example groupList.txt below), you could do something like in this example:

$GroupList = Get-Content .groupList.txt
$StartingContext = "OU=Groups,OU=Location,DC=Coretek,DC=local"
foreach ($GroupItem in $GroupList)
  write ""
  write "Group is $GroupItem"
  dsquery * $StartingContext -limit 9000 -filter "(&(objectClass=Group)(samAccountName=$GroupItem))" | dsget group -members

…and while it’s basically the same dsquery as in the snippet above, the output is much nicer — since we are piping it into dsget, which makes for a much prettier report. 

Now… perhaps my favorite of all, we can do pretty much the same procedure as the previous command, but this time all in PowerShell, and using the Get-AdGroup command (remember to import the ActiveDirectory module!):

$GroupPrefix = "CTS FH "
$MemberList = Get-ADGroup -ldapFilter "(&(objectClass=Group)(name=$GroupPrefix*))" -Properties Members
foreach ($MemberItem in $MemberList)
  write ""
  write "Membership for: $MemberItem"

And that’s it!  You should have a list of group members for the correlating groups. 

So as usual, we have a couple ways to do a few different things.  Have fun with it!



PowerShell v3 and DNS Queries…

2017-07-27T00:01:04+00:00 January 30th, 2013|Uncategorized|

As I mentioned in last week’s post, “PowerShell v2 and DNS Queries…“, it is much easier to do scripted DNS queries in PowerShell v3 on Windows 8 and Windows Server 2012 than it is in v2 — thanks to the new Resolve-DnsName command.  Following along the same lines as the previous post, and using the exact same example hosts, we can show the same correlations and results for comparison. 

We’ll start off with a request similar to our first nslookup in the previous post, but this time using the Resolve-DnsName command:

And as before, the same holds true with out multi-valued results:

On its face, the results are very similar to nslookup results.  However, since we’re dealing with objects here instead of scraped screen executable output, we can actually manage our results very neatly.  Here’s what I mean, as I enclose the object, and only request the “.IpAddress” from it for my two example hosts:

See how neat, clean, and powerful that is?  This same thing works with other object elements, like “.NameHost“, and such.  By the way, I’ve seen some advice posts out on the ‘Net that advise you to use an increment indicator like this:

(Resolve-DnsName $server_name)

…but that will cause you to only get the first result returned!  And sometimes, that may be what you’re after; but in the case of the multivalued host, that’s probably not what you want.

Now, to contrast last week’s post, I’ll show you how we take the 12-line PowerShell v2 script down to a 3-line PowerShell v3 script:

$ARecord = "labdc1.lab.local"
$NameServerQueried = ""
(Resolve-DnsName -Name $ARecord -Type A -Server $NameServerQueried -ErrorAction SilentlyContinue).IpAddress

 …But of course, it’s only 3 lines because 2 of them are variables; but it’s a fully functional equivalent.  And you can start to see how efficient it can be when looped.  And for the sake of completion of the comparison, here’s the results of my v3 script with the “fakehost” multi-valued host:

…and with the original “labdc1”:

So there you have it.  We love the new commands in PowerShell v3, and they are making our lives soooo much easier (once you know about them).   Now, I’m just waiting for the commands I’ve been asking for… Like Get-MyCoffee… and Get-WorldPeace…. and Solve-GlobalHunger




 (Updated 20130815)

PowerShell v2 and DNS Queries…

2017-07-27T00:01:04+00:00 January 23rd, 2013|Uncategorized|

For this week’s (and next week’s) post, I decided I’d kill a few birds with one stone.  Since it’s “PowerShell month” here at, and since I’m still making my way through all the differences between PowerShell v2 and v3 (like we all are), I thought I’d tell you about how I just discovered how a relatively simple thing was relatively hard to do in PowerShell v2, and how it got relatively WAY easier in PowerShell v3:  DNS lookups.

Probably like you, I’ve been doing DNS queries for years in all kinds of scripts and languages — like bash, perl, DOS batch files, and of course, PowerShell.  And up until recently, I treated them all pretty much the same — in that I typically just made a system call out to running OS and used the native DNS client query tool, nslookup.  Of course this requires that I grab the output of the tool, scrape out just the information I want (and ignore other data), and continue on to make use of it.

However, in PowerShell v2, the problem is that when trying to grab the desired results back from the system call, the resulting address from the query is not as easy to discern from the “courtesy” information that is returned along with the answer from nslookup.  What I mean is that searching for the string “Address” could get you in trouble, since you end up with two lines that start with “Address” — the one you don’t want (the address of the server that was queried), and the one you want (the query response). 

And in some cases, they could theoretically be the same value, especially if you’re looping through a list of nameservers and query the name of the server you’re querying.  See what I mean in this unfiltered example query and response: 


Note that the record could be multi-valued too, like this example:

So if I just attempt to grab all the strings that match “Address”, as in the following…:

…I could end up with some strange results.  So, instead, I search for all strings in the form of an IP address, and I implement a simple counter to skip the first one, catch any subsequent ones, and split the result to strip out the words.  Here’s the code for my loop:

$ARecord = "fakehost.lab.local"
$NameServerQueried = ""
$FullAddressList = nslookup -type=a $ARecord $NameServerQueried | findstr "
[0-9].[0-9].[0-9].[0-9]" $counter = 0 foreach ($line in $FullAddressList) { $counter = $counter + 1 if ($counter -ne 1) { write "$line" | %{ $_.Split(" ")[2] } } }

…and here are the results, with the query for the multi-valued “fakehost” host record, as in the $ARecord variable as above (inside my Example.ps1 script):

…and with the original “labdc1” nameserver query, as in my first example:

As you can see, DNS queries are do-able in PowerShell v2, but it’s a pain.  The little snippet above should work just fine inside of a larger loop in a validation script, or on its own, for whatever you need to get done.  And I’m sure there are other ways to accomplish the same thing, but this has worked for me in the past (and present) in PowerShell v2. 

Well — now, there’s a new way of getting the same queries done in PowerShell v3, that is much, much, much easier…  And I will jump into that next week.  See you then!

Next week:   The PowerShell v3 way!


PowerShell Basic Commands 101

2017-07-27T00:01:04+00:00 January 16th, 2013|Uncategorized|

It looks like January has turned into “Powershell Month” here at the! 

And while typically, we write these Powershell-related posts with the assumption that you’re already at least reasonably versed in the language, I thought it might be good to give a few introductory tips to those of you who need the first few basics of Powershell to get you up and running.  Then, you can take these tips and start getting creative with some of the great scripts, loops and commands we’ve talked about here in this blog.

First off, when in the PowerShell command prompt type in “Get-Command” and hit enter:


This will list every PowerShell command available. It is quite lengthy, but can be very helpful if you have the time to scroll through the entire list to discover new and exciting scripting tools.

If you wanted to save this list, you could by outputting it to a file by using the “|” (“pipe”) combined with the “Out-File” command, for example:

Get-Command | Out-File C:Commands.txt

If you are like me and require the list to be sorted by “practical application” then you can sort it by `Module Name’ by simply running:

Get-Command | Sort Module

You can then take it one step further to narrow your search results by filtering by Module name and a “*” (wildcard) as seen here an example of searching for BitLocker:

Get-Command -Module BitLock*

Or if you are looking for a specific command to run to `Enable’ BitLocker:

Get-Command –Module BitLock* -Name Enable* 

From there, if you need usage commands or examples of any newly found Powershell command you can use the “Get-Help” command. The following example would give you helpful information for the “Get-Command” cmdlet as previously mentioned:

Get-Help Get-Command

Or for “Select-String”, the PowerShell equivalent to “FindStr” or the ever-so-popular string search tool called “Grep”:

Get-Help Select-String

One final note to tie this all together: Instead of memorizing the entire cmdlet, module or function names you can use the built-in aliases, which are shorter commands that execute the same command as the long name function, for example: gcm is Get-Command and help is Get-Help

So you could run the following command, which is the same as the above “Get-Help Get-Command”:

help gcm

And you can view the entire list of “Aliases” by running:

gcm -Type Alias

That is all for now! Stay tuned for PowerShell Basic Scripting 101!



Powershell: Script to Easily Find Objects in the SCCM Console

2017-07-27T00:01:04+00:00 January 9th, 2013|Uncategorized|

Recently, I had a need to delete an SCCM advertisement in the SCCM 2007 R2 console, in order to ensure it didn’t run on any of my test machines.  Now, I knew that it wouldn’t run, because it was not being advertised to any collections of which my test machine was a member.  But the advertisement was only a test, and I was trying to clean up after myself.

According to Microsoft (link:, the way to delete an advertisement from the SCCM console is to drill down through the console (System Center Configuration Manager / Site Database / Computer Management / Software Distribution / Advertisements) and right-click -> Delete the advertisement.  Normally, this is a pretty straightforward procedure…  IF you know where your advertisement is located.

You see, the SCCM console in which I was working divided the advertisements into sub folders based on the Publishers name, and I could not find a folder for the Advertisement I was trying to delete.



Furthermore, subdividing the Advertisements as such also rendered the “Look For” search field in the console pretty useless; I would have to “Look For” my advertisement in every folder!

SCCM reports can be pretty helpful, and I was able to run a report that gave me just about every piece of data about the advertisement I wanted to delete – except the path to it; the information critical for deleting the advertisement.

A quick Google search led me to this link:  Here, I found the Powershell script that helped me find my elusive advertisement.

The only inputs for this powerful and very useful script are the name of your SCCM site server, and the SCCM object ID, which can easily be found through the “All Advertisements” report in SCCM.  As it turns out, the folder that contained my advertisement had been accidentally moved under another folder. 

It’s great when you find the perfect tool for the job, as I did in this case.  I hope you find it as useful as I did. I intend to keep this one around for future use. 

Thanks, Tao!


Powershell: Get-ADUser Without Errors…

2017-07-27T00:01:04+00:00 January 2nd, 2013|Uncategorized|

I do a lot of scripting of mass-user searches, server and Home Folder validations, etc., where I rely on the Powershell command “Get-ADUser” in my loops.  And this is one of those cases where Powershell is very forgiving; and as such, things like this can be done a handful of different ways.  Of course, some are better than others…

The shortest and easiest form of the command is often fine enough to get the job done, but not always the best in certain situations.  For instance, if you have an IF loop where you are going through an expected list of users (perhaps from an input file) and trying to retrieve a certain attribute for each, you might be inclined to initially write the loop line something like this:

Get-ADUser -Identity $loopUserId

…and this is fairly standard, of course.  In the resulting loop, it would return something like the standard set of attributes in this capture (using a manual query in my lab for this example)

 However, if you are like me, you might occasionally want to watch the output of your scripts while they run; and you prefer to send nice results to screen (as well as to the output logs) for easy debugging and, well, entertainment. 

And this is where the problem arises with the simple format of the command; you soon become annoyed by all the red error messages for the users that have gone missing since your input file was created, as in the case of this intentional search for a non-existent user:

…this is because by default, the Get-ADUser command will give you a nice set of results when it succeeds, but an ugly red message when there is no result.  Yuck.  This simply won’t do; we don’t want to have to panic as if there were an actual *error* every time we get an empty result on each query in the loop!

Instead, we wish to just get a silent, non-return when there are no results.  So, another way to write the same command so that you don’t get any error messages is by using the -Filter option, like this:

Get-ADUser -Filter {SamAccountName -eq $loopUserId}

In this manual example, you can see that the results are the same as if using the earlier format of the command when successful:

…But this time, we get a nice, quiet, non-result in the event of an empty response; as in the case of the same failed search:

Much better!

Now, you can watch your loop output while having a nice… calm… lunch….



Scripted Home Folder Management with PowerShell Pt. 6 – The Script!

2017-07-27T00:01:07+00:00 October 3rd, 2012|Uncategorized|

This is the last post in my series on scripting user and Home Folder management (see Part 1, Part 2, Part 3, and Part 4 and Part 5 for reference) — it was a lot of ground to cover, but we did it!  Thanks for hanging in there with me.  We’ve created the user and attributes, built the folder, set permissions, added the Home Folder attribute on the user object; all with PowerShell.  You don’t get much more real-world than that!

Now, as promised, it’s time to pull it all together into one example script.

Of course, now that we’re putting all the concepts from the previous posts together, we need to be smart and add a few smart/standard script things; like good use of variables, error checking, and so forth.  Specifically, the new things I’m introducing in this post are:

  • Use of variables  – To make the script portable and easily modifiable
  • Use of command line arguments – To accept the new user’s name as input arguments
  • Use of SubString – To generate a “UserName” (a.k.a. SamAccountName) from a first and last name
  • Check for pre-existing – To make sure we don’t attempt to create an already-existing user name

All of the items above are in the first section of the script below, and the remaining sections are where I pull in the concepts from the previous posts to get it all done.  I don’t want to go into great detail on these new items, but they are necessary to make the script flow correctly and be usable right away as-is.

So, here you go.  You can paste this right into a file (something like provisionNewUser.ps1), launch a PowerShell session, and run it with the new user’s First Name and Last Name on the command line (as explained early in the body of the script). 

And here’s my warning: Don’t ever do what people on the Internet tell you to do; if this script is scary to you, don’t run it.  In fact, only run this in a test lab, until you are comfortable with the specifics.  So there.

# Home Folder Provisioning Demo Script
# Jeremy Pavlov, Coretek Services, 20121003
# Execute in a powershell session, with the new user's First and Last names after the command, like this:
# .provisionNewUser.ps1 Jeremy Pavlov
# # Make sure you run this if not already loaded, for AD-based commands Import-Module ActiveDirectory # # Read in the first name and last name from command line inputs $FirstName = $args
[0] $FirstInitial = $FirstName.Substring(0,1) $LastName = $args[1] $LastInitial = $LastName.Substring(0,1) $UserName = "$FirstInitial$LastName" $MyDomain = "CoretekServices.local" $HomePrefix = "\$MyDomainCorpHomes" $DefaultUserOu = "ou=New Users,dc=CoretekServices,dc=local" # write "First name will be: $FirstName" write "Last name will be: $LastName" write "User name will be: $UserName" write "Home Folder will be: $HomePrefix$LastInitial$UserName" write "" # # See if the user exists $CheckUser = Get-ADUser -ldapFilter "(SamAccountName=$UserName)" # #If user exists, exit! if ($CheckUser -ne $Null) { write "User $UserName already exists! Exiting..." write "" exit } # write "Creating $UserName..." write "" New-ADUser -Path "$DefaultUserOu" -SamAccountName "$UserName" -Enabled $true -Name "$FirstName $LastName" -GivenName "$FirstName" -Surname "$LastName" -AccountPassword (ConvertTo-SecureString –AsPlaintext "ChangeMe123!" –Force) -ChangePasswordAtLogon $true # write "Create $HomePrefix$LastInitial$UserName ..." write "" New-Item -type directory -path $HomePrefix$LastInitial$UserName # write "Setting permissions on the $HomePrefix$LastInitial$UserName ..." write "" $acl = Get-Acl $HomePrefix$LastInitial$UserName $rule = New-Object System.Security.AccessControl.FileSystemAccessRule("$MyDomain$UserName", "DeleteSubdirectoriesAndFiles, Modify, Synchronize", "ContainerInherit, ObjectInherit", "None", "Allow") $acl.AddAccessRule($rule) Set-Acl $HomePrefix$LastInitial$UserName $acl # write "Setting the Home Folder attribute for $UserName" write "" Set-ADUser -identity "$UserName" -homeDrive h: -homeDir "$HomePrefix$LastInitial$UserName" # write "...Complete!" write "" #

…and there you have it.  Now, of course, I could have dumped in a lot of other good practice stuff like input validations and things, or other additional neat features, but I’m only trying to demonstrate the core concepts here from our previous posts in this series.  I don’t want to over-whelm the example and make it difficult or — heaven forbid — boring (gasp!) to read.

But please, if you have a better way of doing it, make sure to drop a comment or two and help out others…

Now go create some users!



Scripted Home Folder Management with PowerShell Pt. 5

2017-07-27T00:01:07+00:00 September 26th, 2012|Uncategorized|

In my last post in this series on scripting user management (see Part 1, Part 2, Part 3, and Part 4 for reference), I left off with a couple different ways to set the Home Folder attribute, using DSMod or PowerShell.

But I thought it was important to spend a moment and stress that when you’re scripting these changes, it’s all about what you *have* available to use as the basis of your queries and changes.  What I mean is this:  If you only have the samAccountName (often called the User ID), you make the query/change one way; but if you have the CN (known as the User Name), then you do it another way.  Let me show you some examples…


As shown in Part 4, if you have the CN — as DSMod requires — you can just make the call directly:

dsmod user "cn=Jeremy Pavlov,ou=Demo,dc=CoretekServices,dc=local" -hmdrv H: -hmdir "\MyCompany.orgDFSPathHomes$username$"

But what if you don’t know the CN, and all you have is the samAccountName?  Then in this case, you must use the samAccountName to first *get* the CN, then pipe the CN through to the DSMod command like this:

dsquery user -samid "JPavlov" | dsmod user -hmdrv H: -hmdir "\MyCompany.orgDFSPathHomes$username$"

In the above example, we’re using dsquery to simply retrieve the samAccountName, as represented by the samid flag; which returns a perfectly-formatted CN that is used as input for the DSMod.  The bottom line is that you can make the change no matter which format you have the User name!


On the PowerShell side of things, you have a similar flexibility.  The PowerShell example I used in Part 4 utilized the samAccountName (as represented by the -identity flag) instead of the CN, like this:

Set-ADUser -identity "jpavlov" -homeDrive h: -homeDir "\MyCompany.orgDFSPathHomesjpavlov"

But if you only have the CN to start with, then we have to go fishing.  We need to do a Get-ADUser with the -like option, and stuff it in a variable, prune that variable down to just what we want, and then pass it on to the Set-ADUser command.  Here’s one example how to get it done, like this:

$Dude = Get-ADUser -Filter 'Name -like "Jeremy Pavlov"'
$DudeSamId = $Dude.SamAccountName
Set-ADUser -identity $DudeSamId -homeDrive h: -homeDir "\MyCompany.orgDFSPathHomes$DudeSamId"

And with that, we’ll press pause, until next time…

Next time…  Let’s wrap this scripting up…  See you then!

Scripted Home Folder Management with PowerShell Pt. 4

2017-07-27T00:01:07+00:00 September 19th, 2012|Uncategorized|

If you’ve been following along in this post series (see Part 1, Part 2, and Part 3 of this series for reference), where I showed you how to create AD users, create soon-to-be Home Folders, and set permissions; all with PowerShell (and some other tools). 

Now, it’s time to stitch it all together by assigning the Home Folder attribute on our user object, and point the attribute to the folder we’ve prepared.  Yes, of course you could just set the Home folder “Connect To” options on the Profile tab of a User object in the Active Directory Users and Computers (ADUC) tool, but that’s not the point.  We want scripting!

So to pick up where we left off last time, all we really need to do is provide a Home folder attribute update on an existing user object.  Of course, we could have done this upon initial creation, but this series of posts is attempting to demonstrate the individual steps that you might encounter in the real world enterprise; either separately or together. 

There are various tools and ways to make our changes, including via the old method outlined in Part 1.  But I’d be remiss if I didn’t confess that much of the time I use good ol’ DSMod.  Here’s what a DSMod line would look like to update our user:

dsmod user "cn=Jeremy Pavlov,ou=Demo,dc=CoretekServices,dc=local" -hmdrv H: -hmdir "\MyCompany.orgDFSPathHomes$username$"

…note that I used “$” (dollar sign), which is a cool way to have the DSMod command utilize the “Windows 2000 User Name”, or the “samAccountName” as the value for this special variable.

*Aside: Why do I keep mentioning the DSMod / DSAdd methods?  I’ll tell you.  It’s because much of the time, I use scripting to parse certain inputs and then generate other scripts that I can hand out to other administrators (yes, script-generating scripts).  And while I can’t be certain that everyone will be familiar with script editing and the PowerShell modules for Active Directory, I can be pretty sure they’ll have a command prompt and DSMod.  There are other reasons, but the rest mostly come down to preference and how the result files look, etc.  So there you go.

However, the new Powershell method with the ActiveDirectory module is pretty nice and easy for this task, too.  Here is the PowerShell equivalent to the DSMod command above: 

set-aduser -identity "jpavlov" -homeDrive h: -homeDir "\MyCompany.orgDFSPathHomesjpavlov"

…or at least its close, although this time I used the “ID” instead of the “Name”.  I think this deserves some closer examination…  So next week, I’ll spend a some time covering alternative inputs/methods to the above, before we move on to troubleshooting and validation, and then sum the whole thing up.

Next time…  A couple more ways to to get it done…  See you then!


Updated 20120923:  command syntax fix

Scripted Home Folder Management with PowerShell Pt. 3

2017-07-27T00:01:07+00:00 September 12th, 2012|Uncategorized|

In this post, I’m following up on Part 1 and Part 2 of this series where I showed you how to create users (and set a few attributes) with PowerShell.  Now that you have your user created and configured, I’m going to show you a bit about Home Folder creation and permission assignment.  Remember that all of these basics are leading toward a single, simplified, scripted elements method of managing Home Folders in the Enterprise.

So let’s create a folder.  Of course, you know how to do that already, so I won’t belabor the point too much.  Picking up where we left off in the last post, you already have a PowerShell session going, with network access to the shares where the folders will be created.  And since PowerShell has native access to the filesystem via its own object paths, you can actually skip the fancy stuff and just do a good ol’ md:

md \serverShare$JPavlov

…or if you’re using a DFS structure, something like this…

md \MyCompany.orgDFSPathHomesJPavlov

I know, I know.  That’s not PowerShell.  So if you really want to use the benefit of PowerShell, you would use the New-Item command like this (sticking with our DFS structure from above):

New-Item -type directory -path \MyCompany.orgDFSPathHomesJPavlov

Okay, great.  At this point, we have a folder, but no permissions yet for the person who will use it.  In order to set the permissions, we’ll stick with PowerShell and…

1.) Build a variable with the existing permissions with the Get-Acl command:

$acl = Get-Acl \MyCompany.orgDFSPathHomesJPavlov

2.) Add-on the permission we want (your permissions may vary!):

$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("CoretekServicesJPavlov", "DeleteSubdirectoriesAndFiles, Modify, Synchronize", "ContainerInherit, ObjectInherit", "None", "Allow")

3.) And then stuff it all back on the folder with the Set-Acl command:

Set-Acl \MyCompany.orgDFSPathHomesJPavlov $acl

There you have it!  We’ve created the soon-to-be Home Folder for the user we created previously, and added permission we want.  So it’s out there if the user can browse around and find it…  But let’s help them out a little bit and deliver it as a mapped drive in the next post.

Next time…  Assigning this folder as the user’s Home Folder via the AD attribute.  See you then!



Load More Posts

Fatal error: Uncaught exception 'GuzzleHttp\Exception\ClientException' with message 'Client error: `POST` resulted in a `400 Invalid instrumentation key` response: {"itemsReceived":1,"itemsAccepted":0,"errors":[{"index":0,"statusCode":400,"message":"Invalid instrumentation key"}]} ' in /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:113 Stack trace: #0 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Middleware.php(66): GuzzleHttp\Exception\RequestException::create(Object(GuzzleHttp\Psr7\Request), Object(GuzzleHttp\Psr7\Response)) #1 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(203): GuzzleHttp\Middleware::GuzzleHttp\{closure}(Object(GuzzleHttp\Psr7\Response)) #2 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(156): GuzzleHttp\Promi in /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php on line 113