Oct 12, 2015

Calculating Bitwise Values

In the last post, I went into a bit of what bitwise AND does, looked at the binary equivalent of the userAccountControl (UAC) value, and showed some visual examples of how calculations are done to find the applied flags.

In this post, I thought I’d go through exactly how you do this. So first off, dust off your calculator and get into Programmer mode. Since Windows 10 has a beautiful calculator, I’ll be doing my demonstration on that.



You’ll cry when you see how easy this is.

  1. Make sure your calculator is set to DEC.
  2. Type in your value.
  3. Observe the BIN value.


Done! When I copy and paste out of the calculator, I get ‭00010000001000000000‬.



Well, sure. In this case, we can use the [convert] class to switch the value to base2 format. Check it out:

[Convert]::ToString(66048, 2)

This outputs the exact binary value I had before with the leading zeroes stripped off -- 10000001000000000. Note all I did was add my value 66048. As an aside, you can also change it to hexadecimal by using base16 format.

[Convert]::ToString(66048, 16)

The output is 10200. If you check the UAC chart, you will find that NORMAL_ACCOUNT (200) and DONT_EXPIRE_PASSWORD (10000) together equals 10200.

You can send the binary and hexadecimal values back to the integer value as well.

[Convert]::ToInt32(10000001000000000, 2) <- binary
[Convert]::ToInt32(10200, 16)            <- hex

Try them. You’ll end up with 66048 for both converted values.

Oh, by the way, if you recall, there is one flag called PASSWORD_EXPIRED (dec 8388608). Don’t spend your time searching this out. It doesn’t get used. Instead, the attribute pwdLastSet with a value of “0” is what is the equivalent of an expired password.



In the last post, we did some bitwise AND calculations by simply lining up the binary equivalents and matching where the 1s fell. If you wanted to do this in calculator, you start with the value at hand, 66048, and subtract the next highest number that is equal to or smaller.

66048 - 65536 = 512
512 - 512 = 0

Once you’re at 0, you’re complete. Since you were able to remove 65536 and 512 integers from 66048, those values are in effect. This method is prone to error but was what I used before learning other methods.

The more effective way to do this is to use the actual bitwise AND operator. This is how you do it.

Ex. 1   66048 AND 65536 = 65536
Ex. 2   66048 AND 16 = 0

I provided two examples. If the value returned is the same as the value you’re validating, it checks out as seen in #1. If the value returns a 0, it isn’t a match. Pretty cool, right?

PowerShell is fundamentally the same. Take a look:

> 66048 -band 65536
> 66048 -band 16



I wrote this more or less as a concept to see how things work. You could push everything into a function to return the values associated with any UAC code you throw at it.

This simple script builds an array of base2 values ranging from 2^1 to 2^26. (Technically, I think it goes up to 31 since we’re dealing with 32-bit.) Why 26? Well, there are no bit flags higher than that in use in UAC so there’s really no point.

Each value is evaluated through bitwise AND against the original integer in $myNum. The output contains the values that evaluated appropriately.

$myNum = 66048
$binArray = 1..26 | % { [math]::pow(2,$_) }
foreach ($bin in $binarray) { 
    if ( $myNum -band $bin ) {
        $binEquation += "$bin "


Output kicks out as such -- 512 65536. Yeah, not real pretty.



(Yeah, right.) I have included a link to the worksheet I created for this exercise called Bitwise_UserAccountControl.xlsx. It’s protected with a password -- bitwise. I only did that so you would know which fields to modify to make it work.


I modified the spreadsheet a little bit from the original versions I was using to make it work better. It now has a conditional formatting calculation that changes the flags row if the bit pattern is proper. :o)

  1. Modify Row 1 and replace it with the binary value of the UAC attribute.
  2. Unlock the spreadsheet and add any other binary values to check against. In the spreadsheet, I only included 2, 256, 512, and 65536 out of laziness. You can add in all of them if you wish -- making it complete.
  3. Watch the Flag row magically change to blue/white with a border if the resulting pattern is true.

Here’s a LINK to the spreadsheet if you’re interested in playing around. Anyway, that’s about all I have. I hope you found this as interesting as I did.



Bitwise Help
Decoding advertFlags
How to use the UserAccountControl flags to manipulate user account properties
[Math] in PowerShell

Oct 5, 2015

My Feeble Understanding of Bitwise

I thought I would set the record straight that by posting something about bitwise does not make me an authority. It doesn’t even make me mildly educated about the concept. In fact, if you have been with me since the beginning, you will know the intention of my blog to create posts that would serve as reminders of how I did something previously -- or interesting stuff that I might have found. With that meager attempt at excusing my ignorance, let’s talk bitwise.

In my last post, I mentioned deciphering userAccountControl (UAC). As an aside, this bitwise stuff isn’t just AD. You can find it in other things like ConfigMgr for example. Remember advertFlags? That post contained some detail on decoding, bitwise, etc., as well.



Back to our previous example, we had a user with UAC value of 66048. We decoded 66048 into its two parts, 65536 and 512. I didn’t go into much detail on how I got those two values, so I thought I’d explain all that here.

First, a background on bitwise AND. Basically, you multiply two binary values together. Since you’re dealing with 0s and 1s, you can only end up with two conclusions -- a 0 or a 1:

0 x 0 = 0 0 x 1 = 0
1 x 0 = 0 1 x 1 = 1

It’s easier to show you what I mean.



Back to UAC 66048. If we convert this decimal value to binary, we get ‭10000001000000000‬. I’ll bring this up again in a minute, but for now, here are the list of flags again, since we’re going to need to reference it.



Ordinarily, you would run a bitwise AND for all these values against 66048 to see what came back as true. Let’s pick just a few as an example (since we already know how it’s going to go.)

Decimal Binary Flag
66048 ‭0001 0000 0010 0000 0000‬
65536 0001 0000 0000 0000 0000 DONT_EXPIRE_PASSWORD
512 ‭0000 0000 0010 0000 0000‬ NORMAL_ACCOUNT
256 ‭0000 0000 0001 0000 0000‬ TEMP_DUPLICATE_ACCOUNT
2 0000 0000 0000 0000 0010 ACCOUNTDISABLE

Added some leading zeroes just to make things line up correctly.

If we lay these values back over the table of all states, this is how it looks. Remember, where the 1s line up ( 1 x 1 = 1) the state is active. The far left column is the decimal equivalent of the binary value.


Removed the leading zeroes here to compress the display.

It’s as we expected. The 1s only line up on the 65536 and 512 values which means it’s a normal account with a password that never expires. GREAT!



There are other bitwise operators such as bitwise OR which is typically used to set a value. If the value already exists, then it doesn’t set it again. I haven’t had a chance to use it so I won’t get into it much.



Bet you’re wondering if there’s a faster way to do this. Well, that’s the great thing about bitwise operators. There is. Next post though.

Sep 30, 2015

Deciphering userAccountControl

There’s been a lot of good information on userAccountControl (UAC) over the years. I was trying to explain a coworker about how it works which got me really thinking about it. I thought I’d try to share my findings with you in case you have a similar interest in learning it.



Let me first describe UAC. The simplest definition, in my opinion, would be to say that it’s a composite status of an object. (Let’s talk about user objects specifically.) A user object can be a variety of things -- disabled, enabled, locked, password expired, etc -- which when the integer value that’s stored in UAC is broken down, represents them. That’s why the account options are multi-select, I guess. :-)


Note that UAC is a 32-bit value. Anyway, this is the LDAP attribute where Active Directory stores the various states of your user account. How many different states can a user account be in, you might be wondering? It’s documented in quite a few places, actually (and now here.)


(Sorry about the screenshot. I had ALL THE INTENTION in the world to actually make it copy/paste, but translations going into Live Writer wasn’t being my friend. I linked it to the article with the values though. :) One last note, if you look at the flag name, it’s pretty clear that not all of those states actually apply to user objects.)



Let’s make this practical and figure out what we’re looking at. Suppose you were goofing around running queries looking at UAC and found an account of interest. The account has a value of 66048. If I run a bitwise AND against it based on the values in the above table, it breaks down into 65536 and 512.

Go on, check my math. 65536 + 512 = 66048.

I transposed the table above to make it easier to look at. Basically, 66048 translates to a normal account with a password that never expires. That makes sense so far right?




When you convert 66048, you get the binary equivalent of 10000001000000000. If you look at the table above, there are definitely values that are missing -- like 1024. If we add those values back in and overlay our binary version of the UAC value, the 1s lay right over the state. Cool, huh?




I mentioned using bitwise AND earlier to figure out what UAC 66048 was composed of. I’ll get into that in my next post since you are probably still waking up from reading this one.

Aug 18, 2015

OpsMgr: Where Are My Events?

Yeah. I know. We’re late to the party. We just got OpsMgr 2012 rolled out. If you want to skip the story time, just go to the TL;DR section.

So, one of the first times I opened the console, I realized there were some events I was looking for that I wasn’t able to find. After carefully combing the console (read: frantically clicking on crap) I came to the realization that no matter which event view I chose, it was restricted to one day.

After talking with one of my engineers, he suggested looking at this article http://www.opsman.co.za/how-to-search-for-more-then-500-objects-in-the-scom-console-group-and-report-add-objects-fields which seems to be referring to searching objects. It did, however, lead to a very useful registry key:

HKEY_CURRENT_USER\Software\Microsoft\Microsoft Operations Manager\3.0\Console\ConsoleUserSettings

I don’t know what most of these settings do and quite frankly don’t want to figure it out. There are, however, two registry values of particular interest:

  • AlertViewTimeSpan | 6048000000000
  • EventViewTimeSpan | 864000000000


They’re pretty self-explanatory -- at least the function. Out of the box, the in-console alerts display pretty much the whole range of what’s captured.

So far as I can tell and if the internet holds true:

  • 10,000,000 ticks in a 1 second
  • 86,400 seconds in 1 day

That means the Alert view value translates to 7 days, and the Event view value translates to 1 day. Eureka.


[ T L ; D R ]

All you have to do is take the existing QWORD value in the EventViewTimeSpan and multiple it by the number of days that you’re interested in. Keep in mind, this applies to all event views as there is no way to limit the date range for event views (that I know of.)

Aug 13, 2015

how to retrieve your ip address with powershell...

update: here is a new method using system.net.dns as noted here:



update: this is how it’s performed in powershell v3 as demonstrated here.

(get-netadapter | get-netipaddress | ? addressfamily -eq 'IPv4').ipaddress


update: this is by far the easiest.

PS C:\temp> (gwmi Win32_NetworkAdapterConfiguration | ? { $_.IPAddress -ne $null }).ipaddress



are you laughing yet?  i know you probably find this topic amusing.  it's really interesting though.  whenever you get over it, i'll do this in the standard cmd.exe interpreter and then in powershell to show you what kind of coolness powershell does.

done?  okay, good.  this is an interpretation of a demo that bob wells did at our smug meeting.  hope you like it.

i should tell you, it's not as simple as the title would lead you to believe.  i like doing that little slight-of-hand thing since it gives the impression that i'm painting a very easy target on my back for your criticism (though it's probably true in other ways)!  the idea is that we want to retrieve just the ip address.  so here we go...

first of all, let's see how you'd get an ip address out of ipconfig.  since i can't get bob's method of regular expression to work, i created my own for this simple, little demo.  following is a series of commands and results to get to the final product. 

to start with, let's get the results of ipconfig and use findstr to pull out any lines that look like an ip address:

C:\temp>ipconfig | findstr [0-9].\.

   IPv4 Address. . . . . . . . . . . :
   Subnet Mask . . . . . . . . . . . :
   Default Gateway . . . . . . . . . :

alrighty, now we have a preliminary list of the addresses we want to use.  problem is, we need to strip it down to only the ip address, getting rid of the subnet mask and default gateway.  we can achieve this by passing the echoed statement back through findstr looking for the word address.  something like this:
C:\temp>for /f "delims=" %a in ('ipconfig ^| findstr [0-9].\.') do @echo %a | findstr "Address"

   IPv4 Address. . . . . . . . . . . :

so far, so good.  now let's get the ip address only.  we take the stuff from before and use it to the for command again to split everything with the delimiter ":", which gives us two tokens.  echoing the second one, we get the ip address:
C:\temp>for /f "delims=" %a in ('ipconfig ^| findstr [0-9].\.') do @for /f "tokens=1,2 delims=:" %i in ('@echo %a ^| findstr "Address"') do @echo %j

ah crap!  see that?  there's a space we have to deal with!  to get rid of it, we'll pass it yet again through a for loop.  you see, the default delimiter of a for loop command is space and tab.  when we pass it back through, we just echo it back:

C:\temp>for /f "delims=" %a in ('ipconfig ^| findstr [0-9].\.') do @for /f "tokens=1,2 delims=:" %i in ('@echo %a ^| findstr "Address"') do @for /f %o in ('@echo %j') do @echo %o


and finally... we arrive at the results we were hoping for.  finally.


okay, let's do the same thing in powershell this time.  maybe we'll find it a little easier...

PS C:\temp> ipconfig | findstr [0-9].\.

   IPv4 Address. . . . . . . . . . . :
   Subnet Mask . . . . . . . . . . . :
   Default Gateway . . . . . . . . . :


so far the results look about the same.  unlike cmd.exe we're not just pushing around text.  in this case, the data is coming back as a string object.  when we run this through powershell, we can actually pull stuff out based on the index of the array.  since we know address is first, we can just call 0 like this:

PS C:\temp> (ipconfig | findstr [0-9].\.)[0]

   IPv4 Address. . . . . . . . . . . :


hmmm.  that was easy, but we're not done yet.  from here, we need to just retrieve the ip address.  the easiest way to do this is to split the contents (truncated it):

PS C:\temp> ((ipconfig | findstr [0-9].\.)[0]).Split()



output is pretty ugly in that format, isn't it?  luckily, all we need is the last value.  just as 0 is the index which indicates the first member of an array, we can use -1 to indicate the very last one.  in this case, the split function moves the ip address to the very end.  now we can capture that array member and bring it back.  check it out:

PS C:\temp> ((ipconfig | findstr [0-9].\.)[0]).Split()[-1]


isn't that cool?


here's a couple of other things that bob demonstrated.  i'm sure you can figure them out on your own though.  no point in be boring you with my narrative:

[MATH]::Round(((Get-WmiObject win32_computersystem).totalphysicalmemory / 1gb),2)

foreach($file in Get-ChildItem){$size =+ $file.length}