Forum Replies Created
-
Posts
-
I haven’t, and I doubt I’ll be able to since I don’t believe the company I’m working for has a maintenance contract.
That is correct. When you use &Right or &Left, it reads however many characters from the direction specified and looks for only that file. It will not deal with partial matches.
So here’s how I have these set up. We have about ten locations and a few different usage profiles within them. All the locations have three-letter codes, so I use those and use three more characters to differentiate the profiles. So I end up with 4-7 profiles per location, all using six letters. Those profile names are the beginning of all the terminal names. Then I do an include from the left with the first six characters. I have another include statement for nine characters because one location is large and has several large departments.
The clients from that larger location still see and try to run the include statement for six characters, so they look for the location and department codes. But since I don’t have a .ini file named precisely that, it doesn’t cause any issues.So you can definitely use two include statements (the two you tested), one looking for the .ini matching the last two characters and one looking for the whole-name match. But if your goal with the whole-name match is to apply a few settings only to one machine, another option would be:
Include=&Right($MAC,6).ini
This looks for a file matching the last six characters of the MAC address, which will obviously be unique. That’s how I’m keeping the device-specific .inis more separate in the inc folder from my area-profile ones.
As to the Exit=All, you only need that statement in the included .ini if you want that .ini to be the last thing processed. For example, I have the display settings at the very end of wnos.ini, with an Include=($MAC,6).ini right before it. If I want to use the $MAC.ini for alternative display settings and not have the defaults in wnos.ini be processed, then I use Exit=All. But earlier Include statements aren’t looking for settings to replace a contradictory default, they’re just adding settings in. So there’s no Exit=All and processing continues where it left off.
I’m not sure if this will answer your question (“would I need to change x or y?”) because I don’t know what you’re trying to accomplish, or what the different files are supposed to do.
The offsets (&Right, &Left) are confusing because they sound like they’re trimming off the specified amount of characters; actually the number you specify determines how many characters it reads.
Using your example, if you have a client called wyse-trmxp, when you say
Include=&Right($TN,2).ini
you are ultimately asking the client to look in the wnosinc folder for a file named xp.ini
If it finds one, the settings will be applied; the same will be true of any clients whose terminal names end with “xp.”– $xx obviously tells it which variable to use ($TN is the most flexible since you have control over its value, but you can use any of them and $MAC is quite useful)
– &Right tells it to read from right to left
– &Left tells it to read from left to right
– and the number after the comma tells it how many characters to read.Does that make more sense? If that doesn’t answer the question, tell me how you’d like the clients to be organized (what groups get what settings, etc.).
Well, it started appearing that our problem was with DNS—namely that most of our clients were not being registered properly in DNS.
I found this thread: http://www.freewysemonkeys.com/modules.php?name=Forums&file=viewtopic&t=6433&highlight=dns
Which helped me fix that problem. I was optimistic that it would solve our check-in failures as well, but I’ve just confirmed that the problem is the same as before, with slightly more detail.Clients check in once and then stop. I normally have check-ins set for every hour, but I’ve set them to 30 minutes to speed up the process so I can more easily notice patterns. After restarting the device, the initial check-in occurs. When the hour rolls around, it turns yellow (2 misses results in a yellow icon). After that they start to turn red and never check in until they’re rebooted.
The only exceptions are the clients which haven’t been restarted since they were registered in DNS. They continue to check in, but as soon as I restart them, they’ll check in once and then stop. I just don’t know what else to try at this point.
Turns out I misremembered deleting those records. I went through and updated them last week. I only deleted them on one subnet to see if it made a difference. So both the CNAME and SRV records are in place and the DHCP tag, but it seems not to be making a difference to the couple clients that have been restarted this afternoon. I’ll wait until tomorrow to see what happens with them overnight.
ConfGen, do you happen to know how the Domain column in WDM is filled? I’m curious what information is supplied where to determine whether the field is empty or not. It’s not specified anywhere in wnos.ini that this machine is part of domain.local. So I would assume WDM just fills it in from DNS, but then there wouldn’t be any clients missing that field. It just doesn’t make any sense to me.
I can definitely try adding them back in.
We used to have them pointing to a 2008 server; when we moved WDM to a 2003 server for compatibility with our 1200LEs I changed the alias records to the new 2003 server, just a few days ago in fact. The problem was happening in spite of the correct server being listed, so I took them out to troubleshoot thinking maybe having more than one method for the clients to find it was confusing them somehow.
Should I try only the DNS aliases without the DHCP tags or manual assignment through wnos.ini? Or is it better to have multiple methods?
Glad it’s helpful!
I’ll mention a couple other things just to head off potential frustrations:
1. I’m guessing you’re using new-ish clients, but just FYI you can’t Include= based on terminal name on versions prior to 5.something. I know for sure that 4.4 won’t do it so I have a legacy solution for our oldest clients.
2. Make sure that those two display settings files (sm.ini and dm.ini in the example I gave) *actually* have a .ini file extension. Since extensions for known file types are hidden by default in Windows 7, it was easy for me to forget and just create a text file. Easiest thing is just to make the files in Configuration Generator, or to make copies of your wnos.ini and then replace their content with the settings you want and rename them.
That probably seems incredibly obvious but it threw me for a loop when I was doing initial testing.
This will only work if modifying the naming convention of the terminals is an option available to you, but here’s what I’m doing to determine which terminals get which RDP connection profiles:
Add a prefix or a suffix to all terminal names denoting whether they are single monitor or dual monitor. For example, if your terminals are named EastBranch01, Warehouse04, etc., you could add a two-letter suffix and make them EastBranch01dm and Warehouse04sm. Then put this line at the end of wnos.ini instead of specifying display settings:
Include=&Right($TN,2).ini
and inside the wnosinc folder, create two files: sm.ini for the single-monitor settings, and dm.ini for the dual-monitor settings.
You could do it as a prefix using &Left instead of &Right, and it could be longer (or even one character if you like). It still involves the work of adding that information to each terminal name, but unlike creating separate mac.ini files for each machine, it scales well. Future effort is reduced to naming the client correctly.
Perfect, thank you! I hadn’t thought to do that. It turns out it works precisely the opposite of how I understood it. The offset is how many characters it reads from that direction, not how many it ignores. Now I can simplify my configuration considerably.
For any future seekers having trouble with the syntax:
As expected, &Left or &Right will make it read FROM that direction. The offset number states how many characters it will read before stopping. So &Left($TN,7) applied to the terminal name “wtSales09” will yield “wtSales,” while &Right($TN,7) would yield “Sales09.” Hope this clarifies for anyone else having trouble with this.I’ve finally found at least part of the answer. Setting AltCacheDisable=yes frees up more memory and my users are able to get that third session open. It appears that’s the most it will handle, but it should suffice until we’re able to replace the 1200LEs.
I’d have to check to see if the RAM is different. I’ll keep an eye out for that as I look at the clients.
The problem, though, is that they don’t seem to have this issue after a factory reset and fresh configuration. Several sessions can be opened with programs and memory still hovers at 40-50%. Then later I’ll get a ticket about the memory error; consistently the two open sessions are all it can handle and the third session refuses to open.
So while memory differences could play a role, the problem seems more software-related. The memory problem is not consistent, and it has only happened since the firmware upgrade. But I would assume that the latest revision of firmware available for the 1200LE would be optimized and cause it to use less memory if anything, rather than using more. Am I wrong?
