managing Enterprise Mode list.

here is my process when I need to add a site to my enterprise mode xml file:

1. open Enterprise Mode Site List Manager
2. bulk add from file, select my enterprise mode xml file.
3. add the site
4. save to xml, select my enterprise mod xml file overwrite it.

I do it this way because I have other people on my team also updating the xml file on their workstations with the site list manager installed. so when I open the List Manager tool on my desktop, I need to load all the sites from the latest version of the xml file, otherwise when I save my list back to the xml, it's not going to have any sites that were added by other people on other machines. (Or when I get a new PC myself...I've had this happen a few times and have had to rebuild the entire list.)

the issue I see here is that when I do this, the "rules version" at the top of the xml file always gets reset back to 1. the way I understand it, IE compares its currently loaded version to the version in the xml file to see if it needs to reload the newer version of the xml. so having it go back to 1 every time I add a site doesn't seem ideal.

i'm assuming that this site list manager tool was implemented to extract the role of managing this list away from the group policy administrator. which is great and all, but surely MS thought about more than one person managing the list from more than one computer.

am I doing this wrong? or understanding the point of the version number incorrectly?

December 10th, 2014 1:00am

Hello John_Curtiss,

Please explain a bit about the how you reset the version number to 1.
Where do you store the xml file?
Based on my test, the version number keeps growing.

For more information about how Internet Explorer compare the version, please take a look at the following article.
http://msdn.microsoft.com/en-us/library/dn756383.aspx
If theres an .xml file in the cache container, Internet Explorer waits 65 seconds and then checks the local cache for a newer version of the file from the server, based on standard caching rules. If the server file has a different version number than the version in the cache container, the server file is used and stored in the cache container.

Best regards,
Fangzhou CHEN

Free Windows Admin Tool Kit Click here and download it now
December 12th, 2014 10:52am

1. open enterprise mode site list mananger.

2. clear the list.

3. add test.com to the list.

4. save to xml, \\server\share\test.xml

5. open \\server\share\test.xml

6. verify the version of \\server\share\test.xml is 1.

7. close \\server\share\test.xml

8. add test2.com to the list in site list manager.

9. save to xml, \\server\share\test.xml

10. open \\server\share\test.xml

11. verify the version of \\server\share\test.xml is 2.

12. close the site list manager.

13. hire another administrator, give him a new pc, install site list manager, and open site list manager.

14.  file/bulk add from file, \\server\share\test.xml

15. save to xml \\server\share\test.xml

17. open \\server\share\test.xml

18. verify the version of \\server\share\test.xml is 1.

December 12th, 2014 11:09am

i'd also like to note that I don't think there is a way to manually change the version of the file.

so in the scenario above, if my file version got up to 20 before step 13, and I got a new PC, and followed the steps above, and when I realized it got reset to 1 I went into text.xml and manually updated the version number to 21, the next time I add a site to the list with site manager (on the new PC), the version number will go back down to 2, because that's what version *that* instance of site manager thinks it should be on. it apparently ignores the version number already existing in test.xml.  

Free Windows Admin Tool Kit Click here and download it now
December 12th, 2014 11:31am

i'd also like to note that I don't think there is a way to manually change the version of the file.

so in the scenario above, if my file version got up to 20 before step 13, and I got a new PC, and followed the steps above, and when I realized it got reset to 1 I went into text.xml and manually updated the version number to 21, the next time I add a site to the list with site manager (on the new PC), the version number will go back down to 2, because that's what version *that* instance of site manager thinks it should be on. it apparently ignores the version number already existing in test.xml.  


By examining with ProcMon on my pc, I found;

The EM Site List Manager (EMSLM) stores its "database" on a per-user basis, at: C:\Users\<username>\AppData\Roaming\EMIESiteListManager\SiteList.xml

This is the "persistent" (auto-loaded when EMSLM is launched) list. This list does not contain a version number.

You should be using the "Export" feature of EMSLM:
http://technet.microsoft.com/en-us/library/dn640693.aspx

After you create your Enterprise Mode site list in the Enterprise Mode Site List Manager, you can export the contents to an Enterprise Mode (.EMIE) file.
This file includes all of your URLs, including your compatibility mode selections and should be stored somewhere safe.
If your list gets deleted by mistake you can easily import this file and return everything back to when this file was last saved.

Important

This file is not intended for distribution to your managed devices.
Instead, it is only for transferring data and comments from one manager to another.
For example, if one administrator leaves and passes the existing data to another administrator. Internet Explorer doesnt read this file.

The exported <filename>.EMIE file, *does* contain a version number. (Also, note that the EMIE file is simply an XML file)

You can also "Save to XML", this also contains a version number.

The XML file for controlling IE EM behaviour, is a standard XML syntax, and so it can easily be edited by hand if needed, to edit the version number as needed. (Notepad or NotePad++, etc is fine for this)


In your scenario, where you have multiple persons with multiple pc's all sharing the ongoing management of the EMIE XML file via EMSLM, it seems to me that this particular scenario was not considered by the EMSLM design/development team.

So, you you consider applying some process/procedural control for managing the site list for your organisation, to minimise the issues you've highlighted.

Use a "central" master file.
Always back up that file up before anybody changes anything.
Always back up the production sitelist XML file (where users computers retrieve the file for IE)
Always examine the current production version number, so that you can verify the new production file will have a later version number.
You can edit the production file by hand if needed to ensure the version number of the updated file is a larger number than the previous production file.

IE itself doesn't care what the version number value actually is - it only compares "current/last version number vs. version number of the retrieved XML file. If larger, load that file"

December 13th, 2014 1:22am

I looked at the import/export feature. So that means every time someone adds a site, they have to save the Xml file for the clients to use, and export an emie file for the next guy to import. Kind of clunky, no? 

"this particular scenario was not considered by the EMSLM design/development team."

I find this a little bit surprising. 

I'll come up with a powershell script and/or Orchestrator runbook to update my list and its version number, rather than messing with the site list manager tool.

Thanks Don. 

Free Windows Admin Tool Kit Click here and download it now
December 13th, 2014 2:50am

I looked at the import/export feature. So that means every time someone adds a site, they have to save the Xml file for the clients to use, and export an emie file for the next guy to import. Kind of clunky, no? 

"this particular scenario was not considered by the EMSLM design/development team."

I find this a little bit surprising. 

I'll come up with a powershell script and/or Orchestrator runbook to update my list and its version number, rather than messing with the site list manager tool.

Well, I did say "it seems to me that this particular scenario..."

That's based on observation, plus reading Chris Jackson's blog about EMIE, and the various MSFT blogs about EMIE.

And a liberal sprinkling of scepticism ;)

I've had quite a few interactions with MSFT engineers over recent years (via Premier cases) and I've concluded that there is a whole lot of unexpectedly surprising gaps in the glue-for-enterprises.

Some products seem to be improving, others, well, not so much.

December 13th, 2014 4:55am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics