Deployment Solution

Hi

I'm investegating the possibility to have one DS server for serving clients in different security zones. I have made a setup with redirected PXE images and this i working as supposed. BUT i still need the mapping for the \\<dsserver>\express share to run any script. I have copied all info from this share to at fileserver in the clients subnet and connects to this one on the clients, bu all scripts are ending with "incorrect function".

Why ? are scripte generated somewhere on on \\<dsserver>\express share and then pulled by the client to run ?? 

From my experience, the scripts are usually pushed from the DS server itself (not via the share).  You mention that you have different security zones.  What do you restrict between these zones/subnets?  This may be what is causing the issue.  Regardless of where the data is coming from, it still needs to contact the DS server for status and to update the tasks/jobs that it was assigned. 

As for now there are no limitations between the sites. I trying to run scripts in WinPe sessions. The Altiris agent is connected so that part seems ok. I have tried several different scripts and created a new with just a line with "pause" but all of them ends with incorrect function". I have also confirmed that the mapping for my "local" express share is ok.

I don't use WinPE at all, but have what you are looking for set up in my environment.

DS is running at Headquarters.
Express share was copied to 7 different sites (images, software, etc.) as we did not want to be pulling vast amounts of data across the WAN connections.
At the beginning of the scripts that need the larger files from these sites, we run code that based on the subnet the computer is on, maps the share to the local server instead of coming back across the WAN.

You can use the getsrv command located in the express share under \TechSup\*OS*\getsrv

*OS* = DOS, Linux or Windows.  This may help you in your quest.

hi again

The problem is not the mappings as I wrote i the start of the thread, since I'm using PXE redirection and I have an PXE server in each of the zones with different images. The issue is not related to pulling data over wan links either, just security policies. Both DS an clients are in the same building. It is okay to open the DS port 402 and 406 between the DS server and the clients but it will not be okay to open the "netbios pacage". Therefore I am curios if this is why I cant run any winPE scripts on the clients. (if I move them into the sam zone as the DS then everything i okay.)

I know you are not doing this over a WAN, but it is the same concept as I assume that you have the security zones in their own subnets.  The only difference in this situation is that you don't have routers in between, just layer 2/3 switches and/or a firewall.

You indicated in a previous post that there were no limitations currently, however, you are jumping back to security being the issue.  What I would do is disable all security on that particular segment (or zone) and see if you can get it to work.  Then, start re-enabling the security.

Also, when it comes to PXE, because I am running multiple PXE servers, I've found a little more success in not doing redirection, but doing what I posted above and allowing the single PXE boot image to map according to subnet.  This is easier to maintain and to ensure that all the pxe servers are using the same things.

Also, I would suggest for trouble-shooting, you take a script that you are having an issue with and insert pauses between each line.  Then watch the script run on the client computer.  This might tell you if it is a specific command that is causing the issue or if there is a more detailed error message that Altiris isn't telling you.

Also, when you've tested that script with pauses, and still get the errors, see if you can run the commands by hand line by line.  If you get different results (which I've seen before and can be a result of the path being too long for altiris to handle, but WinPE or Linux seem to be able to handle it if you do it by hand), then start considering how things are laid out on your server.  If the path is too long, consider mapping a second drive further down the structure to alleviate this issue.

i.e.  f: is mapped to \\ds-server\express
Your script calls for f:\dir1\dir2\dir3\dir4\dir5\dir6\dir7\executable /a;sldkfjkj
You might consider mapping a second drive to a common directory further down the structure.
i.e. g: is mapped to \\ds-server\express\dir1\dir2\dir3\dir4
Your script would then call for g:\dir5\dir6\dir7\executable /a;sldkfjkj

Hi again and thanks for the postings..

I'll try to explain a little bit. We are in at test phase no therefore there are no "firewall rules" between the zones. The issue comes down to this: is it possible to run scripts++ on clients which do not have f: (or any other) drive mapped to \\dserver\express ? Instead i have copied the express share to another server and shared it as express and the winpe has mapped f: against it.

No matter what I write i the scripts I just get "incorrect function" . When I look at a client which I'm trying to run the script on there are just a "blink" of the cmd window, and the the Ds server says "incorrect function" (this i just a script with one line "pause")

The reason for this test is to see if it is possible to have one central DS server with clients in different security zones with as few ports as possible open between the subnets and the DS server.

Yes, it is possible.  That is exactly how I have mine set up.  1 DS server and the information from the express share was copied to local servers.  F: at the other locations is mapped to the server on their subnet, not the DS server.  I'm not sure, but I do think you still have to have some sort of access back to the DS server though even if you aren't mapping to it.  You also have to make sure that everything that the client needs is available on the server it is mapping to.

A couple of things that you should check are that there are no firewalls set up on the client or DS server machines.  If there is, try disabling it.  If that works, then slowly bring things back up.

Also, I would letting it connect back to the DS from that subnet (let F: map to your DS server).  Does that work from that subnet/zone?  If so, then you are missing something that it needs on the file share that you have in that subnet/zone.