derekf's blog

Okay, things get stranger.

In the case where the package isn't found on the local cache... it's actually there, it's identical to the original package, permissions are set correctly, but yet the Installer engine doesn't recognize it... still troubleshooting.

We're removing WINS from our environment.  Don't ask me why, I'm not a big fan of the idea... but they don't pay me to make decisions, they pay me to make things work.

Things work fine without WINS, once you've joined the domain, DNS takes it all over and everything works.

However, we have a utility that does most of those tasks needed to join a machine to the domain -- creates an INI file used to create the machine account, renames the machine to meet our standards, and does the join (among other things).  The person joining the domain specifies their username, password, and their user domain.

At pilot sites where WINS is no longer available, the app started failing.  Research found it was the call to LDAP to try to find the RootDSE.  To reproduce, set your primary and secondary WINS addys to be an invalid IP.  Adding company.com as a DNS suffix makes it work, but apparently the networking folks don't want to add a suffix to the DHCP configuration.

If we go with something along the lines of

DirectoryEntry rootEntry = new DirectoryEntry(LDAP://domain/RootDSE);

it fails with "The server is not operational"

However, specifying the FQDN works:

DirectoryEntry rootEntry = new DirectoryEntry(LDAP://domain.company.com/RootDSE);

So, hopefully this will help someone, although if you're more of a networking guy than me it was probably obvious all along.

Even though I'm no longer involved with group policy, I'm still the go-to guy for issues.

Got a call this morning from a helpdesk guy who was working an issue with Add New Programs not populating.  He'd dug through RSOP and found that two apps had failed to remove. (More specifically, RSOP showed the yellow bang on User Configuration/Software Settings/Software installation, with these two listed as "Removed Applications").  The details for these two apps specified "The removal of xxx from policy yyy failed.  The error was : The installation source for this product is not available.  Verify that the source exists and that you can access it"

A little digging found that both of these apps had been removed from policy with the "Immediately Uninstall" option months ago, and somewhere along the way the app folder was removed from the local servers.  One of the apps had the folder contents available; simply replacing it on the local server was sufficient to allow the uninstall to complete.

For the other app, the source no longer exists.  Most users were able to uninstall with the local cached copy, but this user no longer had that MSI.  Helpdesk will be using MSIZAP to get rid of the registry entries for this app so the user can install the newer revision of this app.

Not sure how long the user has been having trouble.  The lesson to be learned here is to not be in such a hurry to remove the source from the local servers; users may need it for a while after if you've removed it from policy with "Immediately Uninstall", or if you're going to ever push out an app as an upgrade to this one.

The Powers That Be have decreed that the work I've been doing with group policy will be transitioned to another group, so I won't be involved with that anymore.

Since I won't have any things I've found with GP anymore, I guess future posts will involve my other two roles: application packaging and being the junior coder... along with those things I learn in my endeavor to become a not-so-junior programmer -- I've got lots to learn in C#, plus a whole lot of C++ to learn (both native and managed).  Should be fun.

Additionally, I'm a full time college student as well.  There may be some interesting things I find there (or if future semesters are anything like the last one, postings may be sporadic while I scramble to keep on top of my classes)

Okay, it's not new; but it's new to me.  It's the Microsoft Windows Group Policy Guide.  I'm not sure why I didn't pick this up sooner; it's got some useful knowledge for group policy in it (go figure).

           private string TranslateFromGUIDToName(string path)

We got an error yesterday that I'd not seen before, when publishing two separate packages.  Both of them were created by Visual Studio 2008 instead of our typical Wise/InstallShield packages.

The error was "No package in the software installation data in the Active Directory meets this criteria.". 

A web search found nothing useful on this error; I'd started digging into it to maybe be the first to provide something on it -- but during troubleshooting both packages were published without error.  MSI logging wasn't on, so I've got insufficient details to give any theory.  So.. if you get this error, I guess try again later. 

Anybody got a better answer?  I'm still curious about the cause of the error.

I've had this post rattling around in my head for a few months now, but I've never had enough hard data to really flesh it out as well as I'd liked.

I still don't, but I need to get this down on paper.

Apps deployed via Group Policy expire from the local cache.  This can be a problem if the app is removed from the servers, or if you make changes to an existing app that would make its MSI not match the installation (Product/Package code changes, etc).

I don't have the details as to why - whether it's the oldest that gets purged, or least commonly used, or largest; whenever the problem has been seen here, it gets fixed first and the why gets worried about later.  I'd hoped that the next batch would last long enough for me to dig out the details but no such luck.

Want to reproduce the problem?  Simple: 

1.  Publish an app via Group Policy.  Let thousands of people install it.

2.  Let it sit for a while (like I said: I don't have the details as to what causes it to expire)

3.  Change the product code in the MSI on the server.

4.  Try to uninstall the package on the client.  MSI not found, tries to recache from the network, not found there either.

Ran this past a coworker who is an MSI guru; he ran it past his folks and nobody had heard of MSIs not staying in the local cache.  It is entirely possible that it's something specific to our implementation (a policy setting?).  It seems to manifest itself as the same old "Installation Source cannot be found" message when users attempt to repair, uninstall, or upgrade an app.

Have you seen this?  Do you know anything more about it?

Back to the basic apps I started with.

There were a couple of locations where the output was "System.Byte[]" or "System.Object[]". 

System.Object[] appears to happen in "msifilelist", and only on those apps that have a transform.

Given that you're loading everything into a DataRow, code like this will separate out the transform if one exists:

foreach (object a in myDirectoryEntry.Properties["msifilelist"])

{

if (a.ToString().ToLower().EndsWith(".mst"))

dr["Transforms"] = a.ToString();

else

dr["msifilelist"] += a.ToString();

}

The System.Byte[] is a bit more complex.

In a similar way,

foreach (object a in myDirectoryEntry.Properties["productcode"])

works to get the bytes out of the ProductCode property, but the object contains an array.  You can't access the contents of an array from within an object -- a[1] isn't valid, and none of the casts I tried worked.

Found some code online to convert an object to an array of bytes.  It works, to an extent, but there's quite a bit of extra stuff tacked on to both the beginning and the end of the array.  I don't know why - it's got to come from something in that function, but I can't tell where.

Simple enough to loop through and clean it up:

long filetick = File.GetLastWriteTime(file).Ticks;
long badfiletick = File.GetLastWriteTime(badfile).Ticks;

DateTime fileDT = File.GetLastWriteTime(file);
DateTime badDT = File.GetLastWriteTime(badfile);


bool filetrunc = false;
bool badtrunc = false;


filetrunc = IsTruncated(filetick);
badtrunc = IsTruncated(badfiletick);

   if ((fileDT.Date == badDT.Date) && (fileDT.Hour == badDT.Hour) && (fileDT.Minute == badDT.Minute) && (fileDT.Second == badDT.Second) && (fileDT.Millisecond == badDT.Millisecond))


      if (filetrunc || badtrunc)

           if (!(filetrunc && badtrunc))


                {


                      {


                          if (filetrunc)


                              {


                               File.SetLastWriteTime(file, File.GetLastWriteTime(badfile));


                               }


                          else if (badtrunc)


                               {


                               File.SetLastWriteTime(badfile, File.GetLastWriteTime(file));


                               }


                       }


                 }




and



        public bool IsTruncated(long ticks)





        {


            return ((ticks % 10000) == 0);


        }




As always, if there's a better way to do this, please let me know - I'm still a junior coder.

This one is more for my benefit than for yours... the base question for this one is a question that I've been asked more than once at work, and even more than once by the same person.  I figure if I write it out, perhaps I'll be able to explain it better.

Okay - first, the players.

Two domains.  Let's call them DomA and DomB.

Two users.  We can call them UserA and UserB, and for the sake of discussion, we'll put them in their own domains: DomA\UserA and DomB\UserB.

Two app policies (published apps) - one per domain.  Let's call them AppPolicyDomA and AppPolicyDomB to make it easy.

A couple of apps per policy.  Let's go with one that's locked down with a domain-specific group (DomA\MyAppGroup and DomB\MyOtherAppGroup) and one that's open to Authenticated Users.  I don't think I'll need app names.

Okay, given all these players, the base question is:

"If a user from DomB logs onto a machine in DomA, what apps will he (or she) be able to install?"

One opinion that was expressed was that because Loopback Merge was turned on, it'd redirect processing back to the user's own domain.  That's not actually right though, and here's why.

Any given machine - be it in DomA or in DomB, will get only those policies that are linked to that specific machine's OU... and that's going to be domain-specific.  So, the contents of the user's Add/Remove programs will be those apps in those policies that are linked to that machine's OU and the user has rights to -- loopback merge or not, there's nothing that would tell this machine in DomA to go look at DomB's AppPolicyDomB to pull down the list. 

So.. what would DomB\UserB be able to install if he logged onto a machine in DomA?

1) Any app open to "Authenticated Users".  This could be a problem if the domains have different licensing schemes (DomA has a site license for the exact number of DomA users, etc).

2) Any app where DomB's user account is a member of the DomA group.  In our environment, that's pretty much none of them. 

3) All apps assigned to the machine will already be installed. 

Now, you could conceivably use WMI filtering to prevent the Auth Users apps from being available. Filtering was ruled out at a level well above my pay grade so I've done no digging into this one.

Okay, this may not have helped so much, but at least I can point folks at this next time they ask.

Okay, this may be old hat to some of you, but it took me some time to figure it out and I didn't find much useful when searching.

Came across a need to delete a 64 bit registry value from a 32 bit app.  The standard registry delete functions would end up deleting it from the Wow6432Node, which was what was not the desired outcome.

The code to make it happen is pretty simple, but I've got no error checking in the sample code here:

First, the P/Invoke stuff:

 [DllImport("advapi32.dll")]

static extern int RegOpenKeyEx(

      RegistryHive hKey,

      [MarshalAs(UnmanagedType.VBByRefStr)] ref string subKey,

      int options,

      int sam,

      out UIntPtr phkResult );

 [DllImport("advapi32.dll")]

static extern int RegDeleteValue(

      UIntPtr hKey,

      [MarshalAs(UnmanagedType.VBByRefStr)] ref string lpValueName

      );

And then, the meat of the program:

      UIntPtr KeyHandle = UIntPtr.Zero;

      string key = @"Software\Microsoft\Windows NT\CurrentVersion\TestKey";

      string value = "DeleteThisValue";

      RegOpenKeyEx(RegistryHive.LocalMachine,ref key,0,0x000f013f,out KeyHandle);

      RegDeleteValue(KeyHandle,ref value);

The magic numbers 0 and 0x000f103f shouldn't be hardcoded; the 0 is "Non-volatile registry" and the hex number is both "KEY_WOW64_64KEY" (0x100) and "KEY_ALL_ACCESS (0xf003f)".

Ok, part of all this we've already talked about requires that you have the policy's GUID.  But how do you get it?

Simple enough:

        private string Query(string Criteria, string Attribute)

        {

           DirectorySearcher mySearcher = new DirectorySearcher(new DirectoryEntry("LDAP://DC=DOMAIN,DC=MYCOMPANY,DC=com",    null,    null,    AuthenticationTypes.Secure    ));

            mySearcher.ClientTimeout = new TimeSpan(0, 0, 10);

            mySearcher.Filter = Criteria;

            mySearcher.SearchScope = SearchScope.Subtree;

            try

            {

                SearchResult result = mySearcher.FindOne();

                //if exception was not thrown, means it connected successfuly

                if (result != null)

                {

                    if(result.Properties[Attribute][0] != null)

                    {

                        mySearcher.Dispose();

                        return result.Properties[Attribute][0].ToString();

                    }

                }

            }

            catch (Exception ex)

            {

                return ex.Message;

            }

            mySearcher.Dispose();

            return "Not found.";          

        }

with the provision that the "Criteria" and "Attribute" arguments are, respectively,

I found my more detailed notes on the package flags.  A couple of corrections:

The flag “524288” specifically tells whether an app is published or assigned – it’s set for assigned, unset for published.

8 is typically set for published apps and cleared for assigned.

I promised code.

private void SearchAD(string target, string policy, string policyname)

        {

            DirectoryEntry entry = null;

            try

            {

                entry = new DirectoryEntry(policy);

            }

            catch (COMException Ex)

            {

                toolStripStatusLabel1.Text = "Couldn't connect to the specified Active Directory Path - Error = " + Ex.Message + Ex.InnerException;

                return;

            }

            DirectorySearcher mySearcher = new DirectorySearcher(entry);

            TimeSpan waitTime;

            try

            {

                waitTime = new TimeSpan(0, 0, 60); //hh--mm-ss

                mySearcher.ClientTimeout = waitTime; //wait this much time to display results

            }

            catch (Exception Ex)

            {

                toolStripStatusLabel1.Text = "Error = " + Ex.Message + Ex.InnerException;

                return;

            }

            try

            {

                SearchResult result = mySearcher.FindOne();

                //if exception was not thrown, means it connected successfuly

                if (result != null)

                {

                    // Get the 'DirectoryEntry' that corresponds to 'mySearchResult'.

                    DirectoryEntry myDirectoryEntry = result.GetDirectoryEntry();

                    // Get the properties of the 'mySearchResult'.

                    ResultPropertyCollection myResultPropColl;

                    myResultPropColl = result.Properties;

                    if (myDirectoryEntry.Properties["msiscriptname"].Value != null)

                    {

                        int flags = Int32.Parse(myDirectoryEntry.Properties["packageflags"].Value.ToString());

                        if ((myDirectoryEntry.Properties["msiscriptname"].Value.ToString() != "R") || (cbRemoved.Checked))

                        {

                            if ((rbDisplayName.Checked == true) && (myDirectoryEntry.Properties["displayname"].Value.ToString().ToUpper().Contains(target)))

                            {

                                textBox1.Text += "\nInitial Flags: " + flags + "\n";

                                if (checkBox1.Checked)

                                    textBox1.Text += "Path: " + myDirectoryEntry.Path + "\n";

                                textBox1.Text += "App name: " + myDirectoryEntry.Properties["displayname"].Value + "\n";

                                textBox1.Text += "\tFound in policy " + policyname + "\n";

                                if (myDirectoryEntry.Properties["gPCFileSysPath"].Value != null)

                                {

                                    textBox1.Text += "\tPolicy Path: " + myDirectoryEntry.Properties["gPCFileSysPath"].Value + "\n";

                                }

                                if (myDirectoryEntry.Properties["msifilelist"].Value != null)

                                {

                                    textBox1.Text += "\tMSI Path: " + myDirectoryEntry.Properties["msifilelist"].Value + "\n";

                                }

                                if (myDirectoryEntry.Properties["whenchanged"].Value != null)

                                {

                                    textBox1.Text += "\tWhen changed: " + myDirectoryEntry.Properties["whenchanged"].Value + "\n";

                                }

                                if (myDirectoryEntry.Properties["msiscriptname"].Value.ToString() == "A")

                                    textBox1.Text += "Currently assigned.\n";

                                else if (myDirectoryEntry.Properties["msiscriptname"].Value.ToString() == "P")

                                    textBox1.Text += "Currently published.\n";

                                else if (myDirectoryEntry.Properties["msiscriptname"].Value.ToString() == "R")

                                {

                                    if ((flags & 128) != 0)

                                        textBox1.Text += "Removed from policy with allow users\n";

                                    else

                                        textBox1.Text += "Removed from policy with Immediately Remove!\n";

                                }