“Domain Services for Windows” (DSfW) is a suite of technologies in Open Enterprise Server provided by Micro Focus. Of all Micro Focus products, DSfW is most similar to Microsoft’s “Active Directory”(AD). Like most products historically developed by Novell (now owned by Micro Focus), this works on top of eDirectory. Apart from proprietary eDirectory, it uses many open source components like MIT Kerberos and Samba 3.6.3. Thus with DSfW, you have the best of both worlds. “Active Directory” like behavior, and the ability to integrate key Micro Focus products like “ZENworks”.
Open source components in DSfW, Kerberos and Samba help in execution of some AD like features, clientless login after workstation join being the most prominent example. Further, the Samba component is also used for accessing network shares like "netlogon" and "sysvol", which like AD are hosted by all DSfW domain controllers (till OES 2015 there was a bug in novell-oes-samba that disallowed domain level netlogon access. Read the 4.2 section in this blog for the details). The access is done by typing "\\domain name\<sysvol OR netlogon>" in Windows workstation browsers or command interfaces. Access of these shares can be used to make these shares common store for scripts that are executed when domain user logs in, logs off, "powers on" or "shuts down" the system.
2.0 Introducing Login-Logoff and Poweron-Shutdown options
Often, a user spends some time doing certain tasks when he powers on the system, or logs in. Also, he does some tasks when he logs off or shuts down the system. Login tasks can be mapping a network share as a drive, configure printer, launch some application, etc. Logoff tasks can include backing up critical files and folders in network share, cleaning up temporary files, etc. This blog will explain how DSfW can be used to automate these tasks.
While there is no standard term generally used, in this blog I will refer to Login / Logoff / Poweron / Shutdown tasks as "Switching tasks" for brevity.
3.0 Various ways of implementing switching tasks using scripts
The blog will explain how these switching tasks can be implemented using netlogon and sysvol shares. Specifically, we will explain how scripts can be stored and easily accessed in these shares for execution of the tasks. Before we go into these details, let us first classify various ways in which the scripts can be stored and accessed.
1. User and container level switching scripts: In "Active Directory" or eDirectory or any ldap like structure in general, often the users and workstation objects are created in different tree containers. The containers can be organized based on different geographical locations or departments. Accordingly, based on the various functions, the corresponding containers can have different switching scripts. These scripts can be classified as container level scripts, since they are applied on container that corresponds to function.
Alternatively, there can be cases where certain operations like retrieving and backing files to certain locations are user specific. Such operations can be done using scripts that are specific to that user. (If the target or source location is the home directory of the user, then even user level tasks can be performed using container level scripts. That is by using environment variables in startup scripts corresponding to specific names and paths.).
2. Profile based or GPO based switching scripts: In Windows workstations there are various ways in which these scripts can be stored and then accessed. It can be done in a more traditional way, where the script is specified using the "Profile" tab after clicking the properties of user or container in "Users and Computers" console of mmc (Details in section 4.2). Or it can be configured using a specific GPO, launched using gpmc.msc console (Details in section 4.1).
3. Netlogon based or sysvol based switching scripts: In both DSfW and AD, network folders specific to particular domain controller can be created. However, switching scripts require folders that are accessible from any domain controller. This ensures that execution of the script is not dependent on the domain controller that workstation hits when it is switched. “netlogon” and “sysvol” are two such shares.
“Netlogon” share is specifically used for storing switching scripts, mostly logon ones. And “sysvol” share is used for storing group policy (GPO) settings and any corresponding data like switching scripts. But technically, it should be possible to store profile based scripts in any of these, and design a GPO that accesses scripts in any one of these two. However, as we will see later, GPO based access is confined to sysvol folder, and profile based access is recommended to be in “netlogon” share.
4.0 Steps for implementing Netlogon and GPO based switching scripts
The actual content of scripts written is beyond the scope of this article. Suffice to say that requirements should be well understood, appropriate tradeoffs between generic character and complexity of scripts applied, and maintainability considered while writing. Languages also can range from .bat to VB scripts to any other language that is appropriate.
4.1 GPO based switching script: The step by step execution is shared in the link at the end of this section. So I will just give the general guidelines for using this method.
The method involves launching gpmc tool from the joined workstation.
Then it requires creating and editing a GPO that will hold switching scripts, and execute them at appropriate time (that is login, shutdown etc.).
The script needs to be locally created before launching gpmc tool, and pasted at the end of GPO editing step. Copy can be done before editing of the GPO is started.
While there is an option to "Browse" the final network location of script, the link explicitly says "Whatever you do, DO NOT manually browse for the file."
This method does not allow user level control over execution, only container level control.
"Profile tab" option in user properties, is only applicable for login scripts (we will discuss it in next section). However, this option is applicable for login, logoff, Poweron, or Shutdown options.
Here also we need to create a script like we created for GPO based option. After creation, the script needs to be copied to netlogon share located in \\<hostname of "primary domain controller"(pdc)>.<domain name>\netlogon. The reason for copying the script into pdc share is the way in which “sysvol and netlogon share” data is transmitted across domain controllers for DSfW. The pdc initiates one-way sync from its sysvol and netlogon directory to the sysvol and netlogon directory of other domain controllers (dcs). So if the script is copied into domain controller other than pdc, it will be overwritten by the sync process. For this same reason the netlogon share in other domain controllers is made read only. So even accidentally the administrator cannot copy the script to netlogon folder of domain controller other than pdc.
The following screenshots show how the script can be copied to the netlogon folder.
Copy from Local file system
Paste to netlogon share of pdc (here \\frd.gpo.com\netlogon)
The pdc to other dcs sync is a scheduled process running every half an hour in pdc. The scheduled process name is “sysvolsync”. To ensure that the script copied to pdc netlogon share is replicated to other domain controllers, "sysvolsync" command can also be run manually after copying the script. The existence of script in all domain controllers can be verified using command "\\<hostname of dc>.<domain name>\netlogon\" in command line or file browser of the joined workstation.
Once the script(s) are copied to the netlogon folder and verified in dcs, their execution during the startup can be enabled. This is done by referring the scripts in the "Profile" tab of "Properties" of user. The corresponding mmc plugin is "Users and Computers". Please check the following screenshots for specifics.
Screenshots for accessing user profile
After the scripts are configured for execution on startup, the actual execution can be validated by logging out and then logging in the user that is configured.
4.2.1 Note: Accessing of netlogon share using domain name, that is “\\<domain name>\netlogon” instead of “\\<host name>.<domain name>\netlogon” is possible only in OES 2015. There was a bug in novell-oes-samba component of DSfW, that is now fixed in OES 2015.
5.0 Conclusion
Software engineering is all about automating what was previously manual. The process of scripting login and other tasks is the step in that direction. Depending on their need, administrators and end-users can automate switching tasks like login, logoff, power on or shutdown. Shares like netlogon and sysvol, that are internally synced across domain controllers can be used as stores for these scripts. Given the one way sync limitation of DSfW however, the script needs to be copied to pdc only. Further, the profile tab of user properties, or Logon GPO can be used for integrating these scripts into startups and shutdown cases.
Thus in an easy way DSfW users can improve their productivity....!
Support
Documentation
Learning Services
Partner Programs