The impact of the economic crisis on our clients’ buying trends has been substantial over the last several years, with other factors such as the proliferation of malware and the ever-increasing complexity of IT solutions playing a significant role as well. These issues have presented us at XCEND with the challenge and opportunity of helping our clients in bold and innovative ways.

XCEND initially made its name as an Altiris partner, focused on helping its customers gain more value and efficiency out of their Altiris solutions with process and automation.  Over the last ten years, the endpoint management space has experienced tremendous growth and acceptance within the industry. IT infrastructure management as a market has matured from being “nice to have” into a “must have,” and has to a certain extent been commoditized over the last 3-4 years.

IT’s Changing Priorities

Whereas IT has historically been focused on how to better manage and secure the IT infrastructure, the focus has shifted to securing critical data from outside threats and preventing accidental or purposeful data loss. Correspondingly, regulatory governance has had a profound impact on IT budgets and resources. Despite the scope and scale of today’s security threats, there has yet to emerge a single silver bullet to mitigate the risks that organizations face today.

Statistics from a Q3 2010 CIO Survey, conducted by Citigroup Global Markets, shows that overall IT budgets are expected to increase at a modest 1.4 percent for 2011. Spending on security software is estimated to increase by .07 percent over 2010, ranking 4^th in overall growth compared to other segments.

Driving the growth in this market is the cost and impact of security breaches and cyber crime. In a recent survey conducted by CIO magazine, it was estimated that losses from security breaches average $875,146 per incident. Based on the survey responses, the primary impacts that security breaches have had on businesses are financial loss, theft of intellectual property, brand or reputation compromise, fraud, loss of shareholder value, and lawsuits. Furthermore, 52 percent of survey respondents expected security spending to increase at least 10 percent in the next year, with 9 percent planning to increase their spending by more than 30 percent.

Convergence of Endpoint Mgt. and Endpoint Security

Numerous studies have recently demonstrated that security and compliance continue to be top of mind for CIOs and IT organizations. Symantec’s acquisition of Altiris in 2007 sent XCEND down the path of restructuring the company to be better positioned as a trusted advisor to our customers. We help them conquer the challenges associated with protecting their organizations from attacks and ensure compliance with stringent governance policies.

Over the last several years we’ve routinely heard questions about the future of Altiris; in many cases, clients have been concerned as to whether they should they continue to use and invest in Altiris solutions. Our answer has consistently been and will continue to be an emphatic yes. We ask our customers to consider the question, “What do you want from your systems management solutions and vendors over the next five years?” Our responsibility is to advise our clients on the solutions and vendors that can best deliver on their most critical needs.

We continue to evangelize that the convergence of endpoint management and endpoint security is the model that will best help our clients to manage, secure and protect their infrastructure and data. XCEND’s sales and consulting teams recognize that Symantec is at the forefront of this trend and we have never been as bullish about our relationship with Symantec as we are today.

Bet on the Jockey

At XCEND, we believe that Symantec truly has the most compelling story in the marketplace today with regards to security and management solutions.  Our suggestion to our customers is to bet as much on the jockey as they do on the horse, in that they strongly consider the breadth and depth of Symantec’s offerings. It is critical that our sales and consulting organizations are able to articulate the Symantec convergence story and communicate Symantec’s strategy. Symantec’s recent acquisitions of PGP, Guardian Edge, and VeriSign Symantec clearly align with the overall strategy of filling in the gaps and further strengthening the security stack.

Increasing the Effectiveness of IT

For some time, XCEND has been anticipating the trends in the market place and we continue to challenge ourselves to address our customer’s most important critical business challenges. Our mission is to help to increase the effectiveness of IT by not only helping them better manage their infrastructure and secure data, but to measure the effectiveness of their IT operations with our MetriX Real-time Dashboard solution. Additionally, we introducing several advance workflow applications for Service Catalog and Service Request that will dramatically help IT increase their service management capabilities to their end users. Our expertise extends to the following practice areas:

• Endpoint Management
• Endpoint Security
• Compliancy
• Real-time Analytics
• Service Desk
• Asset Management
• Workflow Development

XCEND continues to invest in our security practice and has matured into much more than just an Altiris partner.  The mix of our pipeline of opportunities has changed dramatically over the last 12 months, with nearly 22 percent being comprised of security opportunities. We have put initiatives and campaigns in place to increase that percentage to nearly 45 percent by the end of 2011.

XCEND maintains sales and technical certifications for the following Symantec Security solutions:

• Endpoint Protection / Protection Suite
• Network Access Control
• Data Loss Prevention
• Control Compliance Suite
• Security Information Manager (SSIM)
• Enterprise Vault

The recent changes in the Symantec Channel Program will help to drive our investment and expansion into security. We look forward to working with our field counterparts to drive greater value for our clients by delivering solutions and services that will have a dramatic impact on how they secure their enterprises. In the last six years, XCEND has done business with well over 600 customers, which presents us a tremendous opportunity to re-engage and expand the footprint of Symantec solutions within these accounts.

As the end of the year draws close, we look forward to closing out 2010 on a positive note and with significant momentum in order to strengthen our partnership with Symantec in 2011.

Analytics continues to be a growth segment in the industry, yet I find it fascinating and troublesome that IT lags behind its business counterparts in making information an integral aspect of their operations. Adoption rates remain pretty low for business users at approximately 23%, but these adoption rates are even lower for the IT organization, despite the fact that IT is largely responsible for supporting the traditional Business Intelligence solutions that are being deployed today.

The challenges and complexity for IT organizations is only growing in scale, as many mid-market and enterprise organizations rely on a vast number of IT management and monitoring applications. Our in-house research indicates that this number routinely exceeds 100 separate solutions. Consider the number of siloed organizations in IT: Data Center, Networking, Storage, Infrastructure, and Security to name a few. Each of these departments is easily using anywhere from 6-12 applications, at minimum, each with their own set of reporting and alerting capabilities.

Considering the vast amount and variety of data that is being generated by the IT organization, how can IT turn all this data into information that can fuel gains in performance, efficiency, and alignment with the business?

IT has to first figure out how to aggregate data from across the organization and provide a unified view of this information, allowing for intelligent, timely decisions on how to react to the most critical operations.  IT organizations can no longer afford to rely on the fragmented reporting and traditional dashboards solutions that focus on what, why and when. Data mining has its place, but IT management needs to be more proactive than ever before.  They need instant, real-time access to information and  the ability to get the right information to the right people at the right time.

Secondly, IT needs to recognize and prioritize the management of information with the organization.  Adopting and adapting the principles of business intelligence within the IT organization can deliver the same kind of value it delivers to the business: the ability to make informed and timely decisions that can impact the organization.  It is surprising how many IT workers and managers dismiss the importance of data management.  I routinely hear how real-time analytics is a “nice to have” and not a “must have” for IT.  It’s not surprising, however, that the higher within the IT hierarchy we are when we discuss the importance of information management, the more important visibility and transparency is to IT and the business.

Finally, IT needs to leverage a solution that can serve as that single pane of glass into IT operations. There are a great deal of complexities and inefficiencies associated with generating reports or dashboards from disparate systems and databases.  Unfortunately, many of the traditional BI solutions do not scale or serve the unique requirements of the IT organization.  In order for IT to effectively address real-time analytics, they need a solution that will not require finding and/or training of specialized resources that are capable of supporting traditional BI solutions.

More troubling for IT managers trying to leverage traditional BI tools is finding a solution that architecturally will scale to all departments and systems and that will not require writing connectors to APIs of a solution’s proprietary data-mart or data-store.  IT requires solutions that are more open in nature and allow them to query directly to the sources of data they need access to, minimizing costs associated with software, implementation services, training and support.  An open architecture enables all of IT to tap into required data without the worry of cost and complexity, normally associated with developing real-time analytics.

MetriX Real-Time Dashboard was developed as a direct result of our clients’ unique requirements as IT organizations.  MetriX allow organizations to easily and quickly build real-time, unified views of all their most critical and strategic Key Performance Indicators.  To learn more about how MetriX can increase visibility and transparency across the IT organization, please visit the MetriX home page or our Live Events page for upcoming webinars & demonstrations.

• Symantec Deployment Solution v6.9sp4 Installed
• PXE Server and DHCP Server Running Correctly in your environment
• WIN PE as PXE Option
• Windows 7 WAIK Installed on Machine other than Deployment Server
• Symantec Notification Server 7.X with Patch Management Solution Installed

Download a PDF version of this document

Links:

Windows 7 AIK - http://www.microsoft.com/downloads/en/details.aspx…

REMEMBER: Test imaging first without any patches. Once that is working correctly add patches as needed, as certain patches can break an image (not permanently, but would have to be removed from the Updates$ share).

Steps:

1)    Install Windows 7 WAIK from Microsoft’s site onto any Windows XP/Vista or 7 client box.

2)    Create a folder on the Deployment Server eXpress share under WAIK folder called Tools_v2

3)    Copy the contents of the following directory, C:\Program Files\Windows AIK\, on the client machine to the WAIK directory, renaming the folder Tools_v2.

4)    Install the version of Windows 7 on a system to create our base image.

5)    Patch to the latest level. However, this will be the last time we have to update the image, as after this point, after the image is laid down, all enabled patches will be installed, with no more quarterly security updates.

6)    Modify all settings in the user profile to how you would like the default user profile to look like. Remember, we can change a lot of these after the fact. However, we would like to get it to as close as possible of what we want the end result to look like. REMEMBER: do not install either the dagent or the NS agent. We will do this post imaging, via the SetupComplete.cmd file (formerly known as cmdlines.txt). Now onto creating our unattend.xml file (formerly known as sysprep.inf)

7)    On the client machine with the Windows 7 AIK installed, insert your Windows 7 DVD and Launch Windows System Image Manager. We will now create our unattend.xml file (formerly known as sysprep.inf). DO NOT install the WAIK on the computer you are making the Windows 7 Image on.

8)    The main areas of the unattend.xml file we are concerned with are,

Generalize (Phase 3)

Specialize (Phase 4)

Out of the Box Experience, also known as OOBE (Phase 7)

Fig 1. Opening Windows System Image Manager

Fig 2. Adding Windows install.wim image

Fig 3. Choosing Windows 7 Image Type (Should be either Enterprise or Professional)

Fig 4. Create a New Answer File

Fig 5. Disable workstation from becoming a network browser

Fig 6. Disable workstation from becoming a network browser

Fig 7. Configuring Language Settings

Fig 8. Configuring Language Settings

Fig 9. Configuring Language Settings

Fig 10. Configuring Computer Name and Company Information

Fig 11. Configuring Computer Name and Company Information – Also put in KMS/MAK Key

Fig 12. Disabling EULA and configuring Network Updates and Location

Fig 13. Disabling EULA and configuring Network Updates and Location

Fig 14. Configuring Built In Administrator Accounts Password

Fig 15. Configuring Built In Administrator Accounts Password

Fig 16. Configuring Additional User Account (Required)

Fig 17. Configuring Additional User Account (Required)

Fig 18. Configuring Additional User Account (Required)

Fig 19. Enabling Remote Desktop

Fig 20. Enabling Remote Desktop

Fig 21. Enabling Automatic Domain Join for Computer Account

Fig 22. Enabling Automatic Domain Join for Computer Account

Fig 23. Enabling Automatic Domain Join for Computer Account

Fig 24. Enabling Automatic Domain Join for Computer Account

Fig 25. Configure Language for OOBE Settings

Fig 26. Configure Language for OOBE Settings

Fig 27. Configure Timezone for OOBE

Fig 28. Saving unattend.xml file to Desktop –Ignore warnings, as these are settings we did not set.

Note:

Phase 1 (WinPE) is not used, as the PXE Boot Disk Creator is what replaces this.

Phase 2 (Service Mode) is no longer used; this was for Windows Vista driver injection.

Phase 5 (auditSystem) is for adding drivers the old fashion way, putting them in a directory. However, requires another sysprep command after it boots into audit mode. Thus requiring the Altiris dagent to be installed into the image

Phase 6 (auditUser) see above.

(9) Copy the unattend.xml file to the Windows 7 Base Image Machine, C:\Windows\System32\Sysprep\unattend.xml

(10) Copy the unattend.xml file to the eXpress Share\Sysprep\unattend.xml.

(11) Run the command, C:\Windows\System32\Sysprep /generalize /oobe /shutdown. After the computer is shutdown, create a new machine in the Altiris DS console using the primary lookup key, in most cases specifying the MAC address as follows:

(12) Now create a “Create Disk Image” job to capture the image we have now created. Drag and drop this job onto the newly created machine, boot up the machine and make sure it PXE boots into WinPE. It will now capture the image up to the eXpress share. NOTE that while I am using WinPE in this step, you can also use Linux PE, but for this step only. For distributing the image, we require WinPE to use the Microsoft utility, dism.exe, to inject the drivers and patches into the offline image.

(13) In order for patches to be automatically installed, we must create a share on our Symantec Management Platform Server (Altiris NS). So on the Notification Server with Patch Management installed, share the following directory: (Installed directories may vary, so change accordingly) C:\Program Files\Altiris\Patch Management\Packages\Updates, as Updates$

(14) Now that we have our image, we must start to create the directory structure for our drivers. So on the Deployment server; create the following directory structure under the eXpress share. REMEMBER: Windows 7 looks for drivers’ recursively; therefore these names are not built in stone.

\HWII

\HWII\Windows7

\HWII\Windows7\ModelNum

\HWII\Windows7\ModelNum\audio

\HWII\Windows7\ModelNum\misc1

\HWII\Windows7\ModelNum\misc2

\HWII\Windows7\ModelNum\misc3

\HWII\Windows7\ModelNum\misc4

\HWII\Windows7\ModelNum\sec1

\HWII\Windows7\ModelNum\sec2

\HWII\Windows7\ModelNum\sec3

\HWII\Windows7\ModelNum\net

\HWII\Windows7\ModelNum\video

\HWII\Windows7\ModelNum\wnet

(15) Download all drivers and extract each into their appropriate model\type folder, as created above. NOTE – this step may have to be revisited if after imaging a machine, not all drivers are present. This is a cyclical step, to be repeated until all drivers are identified for each model of the Hardware Independent Image.

(16) We will now create a custom setupcomplete.cmd file, in the express share, \Sysprep folder. You can also have custom setupcomplete.cmd files for each model, if need be. However, in this example, I did not require this. If this is the case, you would have to modify the first script, REM Hardware Independent Script Portion. An example of the setupcomplete.cmd file is shown below:

(17) We will now create our job to distribute our Hardware Independent Image

(a)Create a Distribute Disk Image, pointing to the image created in step 12. Make sure to pick Windows PE as the boot environment. Also, my suggestion is to use x86, as it is more reliable for drivers.

(b) Create a Run Script; with the following code (Also, pick the same Windows PE boot environment as step A). You will want to edit the following lines,

(i) conExpressShare, if you change the default share letter

(ii) conUNCPath, the \\NSServer\Update$share

(iii) conUserName, username with rights to the above share

(iv) conPassword, password for above username

(v) conType, for if this is a x86 or x64 image

(vi) conTempDirectory – Temp folder on the conExpressShare Drive

(c) Create a Run Script, with the following code (Also, pick the same Windows PE boot environment as step A)

(i) This script will need to be modified in the REM Get Production Name section for your particular environment. You want to map the model that Altiris DS gets to the name of the folder you stored all that models drivers. i.e. A HP z200 Workstation is reported to Altiris as 0B40h. Therefore, I have a folder named z200, but the script has to change the model number to the folder number. As seen in the line, If %model%==”0B40h” set retrieve=z200

(18) Add any additional tasks to run to install additional software. REMEMBER: if you want best practices, you don’t want anything in your base image – even Microsoft Office, as then we never have to update this image, only the additional task. For different software builds, we then have a different job that starts off with the same 3 first steps of this, but then adds all the additional tasks to install all the required software.

The following entry is Part Two in a four-part series describing how to create a ServiceDesk 7 smart task to assign the incident being viewed to the current worker and that worker only.

Part 1: Creating the Smart Task

Part 2: Creating the Workflow Model (download a PDF)

Part 3: Configuring and Publishing the Workflow Model

Part 4: Using the Newly Created Smart Task

PART TWO: Creating the Workflow Model

(1) Open up the Workflow Designer, followed by (2) Create a Webform Project.

(3) Click on AssignToMeEscalation to edit the Service ID.  This is to enable us to be able to use Service Desk Workflow Components.

(4) Click on the Project Name, AssignToMe, so that we can change the Service ID. This is to allow us access to use Service Desk Workflow Components.

(5) Now, click on the Libraries tab, so we can add the Service Desk Workflow Components to our Toolbox.

(6) Click on Add, Custom Libraries,  and choose all custom libraries that start with SD, as shown below. Click Add and then OK.

(7) The following will ask you to “Configure Relational Items”; click on select all then OK.

(8) Click Input Data so that we can define the input from our Smart Task Created in Part I. We will call this variable MessageID.

(9) We can now add all the required components for our workflow. Click on Model:Primary and delete the “Create Notification Server Credentials”.

(10) Add the Service Desk components to the Workflow Toolbox. Add the “Process Manager Login Component” and connect to the start component, as shown below.

(11) Add a “Terminate and Transfer Dialog Box” and connect the “Login Failure” or the “Process Manager Login Component”. Then copy the End Component and connect that to the “Terminate and Transfer Dialog Box”, as shown below.

(12) Add a “Get Item From Exchange Component” and connect to the “Process Manager Login Component”.

(13) Now add a “Form Builder Component” and connect this to the “Get Item from Exchange” Component Item Not Found Path.

(14) Add Embedded Model.

(15) Add Variable Exists Rule Component.

(16) Add “Equals Rule”.

(17) Add “Variable Exists Rule”.

(18) Add “Equals Rule”.

(19) Add “Form Builder”.

(20) Add another “Form Builder”.

(21) Add “Terminating Form Builder”.

(22) Copy End Component.

(23) Add “User Has Permission Rule”.

(24) Add “GoToComponentByName”.

(25) Add 2 – “Add new Data Element”.

(26) Add “GetUserByEmail”.

(27) Add “Create Log Entry” and “New Data Element“.

(28) Add “Single Value Mapping”.

(29) Add “Add New Data Element”.

(30) Add “Add Items To Collection”.

(31) Add “For Each Element in Collection”.

(32) Add “SendCompleteWorkflowMessage”.

(33) Add “Terminating Form Builder”.

(34) Connect to End Component.

(35) Now add the Error Handling Section.

(36) Add “Exception Trigger”.

(37) Add “Create Log Entry”.

(38) Add “Terminating Form Builder”.

(39) Add an End component, and connect to the “Terminating Form Editor”.

(40) From here, I am going to clean up and give our components more descriptive names, along with tidying up the model. The final output is shown below.

In the next part, we will name the components variables and make all the final connections.

In order to push out the Altiris NS Agent via the Altiris Install option, the account used to push the Altiris Agent (usually the application identity account, though this can be overridden) must have the following security rights:

• Write access to the machines ADMIN$: Administrative shares cannot be disabled or else our push technology will not work.
• Part of the local administrators group: This is to allow us to spawn the process to install the software.
• WMI Management enabled on the machine: This is how we spawn the actual process to perform the agent installation.

While it is possible to make the Altiris application identity account a domain admin, this is not recommended from a security perspective, as domain admins have more than just administrative rights for the computers in the domain. With restricted groups, you can limited the scope to specific machines, something that you cannot do with a domain admin account. Remember, after an installation is performed, we actually don’t need any rights, as the Symantec Management Agent runs in the SYSTEM context.

The following procedure is the only way, outside of login scripts, to push out the Altiris Agent when there are multiple domains.

Steps:

1. Open up “Active Directory Users and Computers.”
2. Create a “Domain Local” Security Group. For our example, we will create the group “Local Workstation Administrators.”
3. Add the Altiris NS Service Account to the group created in step 2.
4. Close out of “Active Directory Users and Computers.”
5. Open up “Group Policy Management.”
6. On the OU you would like apply the Altiris application identity into the local administrators group, right click and choose “Create a GPO in this domain, and link it here.”

7.  Next, name the policy.

8.  Right click on the Policy and Choose “Edit” to open the following screen:

9.  Expand Computer Configuration/Policies/Windows Settings/Security Settings and Click on Restricted Groups.

10. Right click on Restricted Groups and Click Add Group.

11. Name this group the same as the group you created in step 2.

12. Click OK to bring up the following screen:

13. Since we want to append our group to the local administrators group, not overwrite everything in the local adminstrators group, we want to click the “Add” button next to “This group is a member of”.

14. In the box that is brought up, type in “Administrators”, as is shown below:

15. Click Ok, Ok, then close out of “Group Policy Management”.

16. On a workstation that is under that OU, open a cmd prompt and run gpupdate/force to apply the settings (by default this will happen in 15 minutes or so, depending on your active directory setup).

Before:

After:

17. You are now finished. The “Local Workstation Administrators” Group has been added to the local group, “Administrators.”

Agent Push Troubleshooting

To verify the security rights:

1. From the NS Server, logged in as the Application identity, click on Run. Type in \\workstationname\admin$. If you get anything but the files in the remote computers Windows directory, then you do not have sufficient rights.
2. From the NS Server, logged in as the Application identity, open up computer management. From computer management, right click and choose “Connect to another computer”.  Type in the name of the workstation you are attempting to push the Altiris Agent to. Once it connects, see if you can view Local Users and Groups. If not, you do not have administrators rights.

Check Installation files:

1. Under C:\Windows check to see there is a file called AeXNSCInstSvc.msi. This is the installation file. If it was not copied down, check (Verify the Security Options, #1)
2. Check the installation log file AeXSWDInstSVC.log.

[Download a PDF version of this entry]

Ever since the release of Windows Vista and the UAC (User Account Control), installing software via logon and startup scripts has changed. In most situations, most Altiris administrators will opt to rollout the Altiris Agent with an automated push via the Altiris Notification Server. However, this push only occurs at scheduled times. Using group policies, we can install the agent whenever a machine is booted up.

This also helps when it is not possible to get local administrator rights on the computers you will be managing due to security or political concerns, so that the active directory administrators will be taking care of the agent installations. The following document will show you how to create a Group Policy object and apply it to workstations. It will also give you the vbscript to accomplish this. The script will first check for the existence of the Altiris Agent; if not found, it will install the Altiris Agent. If the agent exists, it will check the agents’ version. Version 6 agents will be upgraded; if version 7 is found, it will then check that it is pointing to the correct server and make any necessary redirections.

Note: You must have domain admin rights to perform these tasks.

1. Open up an explorer windows to your local domain controller’s NETLOGON share, as shown (my network in this example is thenetworkguru.local).

2. Copy the file AeXNSC.exe from your Altiris NS server nscap share to this directory. This file will be located at \\nsserver\nscap\bin\win32\x86\NSClient Package.

3. Download the PS Utilities from the following Microsoft site: http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx. Extract the files, then copy the psexec.exe to your domain controller NETLOGON share, where you copied the AeXNSC.exe file also. This is needed for Vista/7 clients as UAC runs the startup scripts under a limited SYSTEM account context. However, we need full SYSTEM access. That is what psexec is used for.

4. Under the domain controllers NETLOGON share, right click and create a text file called InstallAltirisAgent.vbs. Be sure that its file extension is vbs, not txt. This may require you to turn off the Folder Option “Hide Known File Extensions.”

5. In the file, copy the following script:

6. Change the constants below, replacing thenetworkguru.local with your active directory domain name. Also replace hqns01.thenetworkguru.local with the Fully Qualified Domain Name for your Altiris 7 Notification Server.

conPackageLocation

conInstallPath

conCMDOptions

conServerName

conPSExecLoc

7. Open up Group Policy Management on one of your active directory domain controllers (this could be different if on a Windows 2003 domain controller).

8. Right click on the OU or Domain that you would like to apply this group policy object; click “Create a GPO in this domain”, and link it here. In our example I will name it “Computer Startup Policies.”

9. Right click on the group policy and click “Edit”; this will bring you to the following screen:

10. We will now want to expand Policies–>Windows Settings–>Scripts. Click on Startup.

11. Click on Add.

12. Click browse and type \\domainname\NETLOGON in the filename section as shown below.

13. Now click on the InstallAgent.vbs and select Open.

14. Click OK.

15. Click Apply and then OK.

16. Close all windows and restart a machine in the chosen OU. If they didn’t have the Altiris Agent, they should get this upon next bootup.

Note:

To troubleshoot, the first thing to check is that the file AeXNSC.exe is copied to the local computers C:\Windows directory. Check the event logs for any errors, and if the file is copied down but the agent not installed.

Please note that this is to implement a centralized PXE server and WoL support via the network infrastructure. This functionality can be emulated using WoL proxies on each subnet, but that is not the purpose of this article.

We will start with our example network diagram:

Both PXE and WoL are based on broadcast technologies. This is the reason you see that WoL and PXE work fine on the network that the Deployment Server is installed on. They do not, however, work on any other network because routers drop broadcasts by default.

For PXE to function in the above shown scenario, we need to enable UDP broadcasts of ports 67, 68, and 69. Since we are using Cisco equipment, the command to forward broadcasts is “ip helper-address”. By default, this command forwards ports 37, 49, 53, 67, 68, 69, 137, 138. We must next determine where to place this command. From the diagram above, the computers which we would like to PXE boot are on the 192.168.0.0/24 network.  We must therefore enable UDP forwarding on this network. In order to do this, we will have to configure the setting on the router closest to them (some of you may know this as the default gateway for these clients).

On this router/Layer 3 switch (in our case REMOTE_ROUTER), we must configure the ip helper-address on the appropriate interface/vlan. In our case, this interface is fastethernet0/0 on the router, REMOTE_ROUTER. This could just as well be a VLAN interface, in which you would replace “interface fastethernet0/0” with “vlan remoteVLAN”, with “remoteVLAN”, being the name of the VLAN for the 192.168.0.0/24 network. The commands to do this in a Cisco environment would be:

enable

conf t

interface fastethernet0/0

ip helper-address  10.0.0.10

After saving this configuration, PXE on your remote LAN will now work.  What this command in essence is doing is whenever it sees a PXE broadcast packet, it sends it to 10.0.0.10, the deployment server. One question I get a lot is if there is already an ip helper-address configured for our DHCP server, do we replace it? The answer is no. Cisco routers will send the packets to all ip helper-addresses listed. If there is nothing configured on the Deployment server for the client to do, it will be passed up as a boot option and move onto the hard drive.  Just note that if you do remove any previously configured ip helper-addresses, DHCP may not function.

Before we get into a discussion of how to configure WoL, we should first discuss the security implications. In order to configure WoL, we are required to turn on what is known as directed broadcasts on the clients’ gateway, REMOTE_ROUTER in our case. What a directed broadcast does is when you ping the network broadcast address, in our case 192.168.0.255, a ping is actually sent to every machine on the 192.168.0.0/24 network. So in our case, 192.168.0.1-192.168.0.254 would respond, if they are active, to our ping. The security concern here is that this could be used in a DDoS (Distributed Denial of Service) attack. For example, say I spoofed (faked) the deployment servers ip address from my laptop and sent a ping to the networks broadcast address. All machines would send ping replies to the deployment server, not to my laptop. This is the reason why directed ip broadcasts are disabled out of the box by Cisco.

In order to attempt to secure directed ip-broadcasts, we will use what is known as an ACL, or Access Control List. We will limit directed ip broadcasts to only one port, port 402. While it is still possible to create a DDoS using port 402 spoofing the Deployment Servers ip address, this requires an attacker to spoof the Deployment Servers IP address and use port 402 for their directed ip broadcast ping. Therefore, a potential attacker would have to do some “fire walking” to determine what ports the configured ACL will allow through and from what IP addresses. At that time, your networks intrusion detection system should pick up and alert on it. While there is only a slim chance of this happening, it should be noted.

Let’s next discuss the configuration on the servers’ gateway, CORE_ROUTER, used to forward WoL packets to the remote clients. We first must enable UDP forwarding of port 402, which is the default port Deployment Server 6.9sp4 uses for WoL. To verify which port your Deployment Server installation is using, you can install Wireshark, run a network capture, a type “wol” in the filter box, and find the UDP port required, as shown below. Look under the Dst Port:, whatever is in parentheses, is the UDP port number.

Since by default “ip helper-address” does not forward port 402 (as shown in the previous PXE section), we must first configure it to forward this port:

enable

conf t

ip forward-protocol udp 402

This will now allow the ip helper-address to forward our WoL packets to the remote routers. This will only allow packets from UDP port 402 to be forwarded, however; we still have to setup the actual forwarding on the CORE_ROUTER. So for each remote network, we will be required to add an ip helper-address on the router interface, which is the servers’ gateway.  The configuration is as follows:

interface fastethernet0/1

ip helper-address 192.168.0.255

This will now allow us to forward WoL packets from the server. However, the remote sites are yet to allow directed broadcasts. So our final step is to enable directed broadcasts for port 402 on our remote subnets, REMOTE_ROUTER in our case.  I have listed the ip helper-address in the configuration below. However, if you enabled PXE previously, you will not have to add this again.

enable

conf t

access-list 101 permit udp host 172.16.15.130 any eq 402

int fastethernet0/0

ip helper-address 10.0.0.10

ip directed-broadcast 101

From here, WoL should now work via Deployment Solution. You can also use WoL via Notification Server (if it is on the same bpx as DS, or else you must make the same changes as above for the NS server); under the advanced settings, change the port to UDP 402, as shown below.

Symantec will release a new option as part of its application virtualization product to virtualize Internet Explorer 6. Many customers cannot move to Windows 7 because of numerous dependencies on the older web browser. Their approach enables side by side Internet Explorer v8 and v6 compatibility, but more importantly the solution offers a secure implementation that is invisible to the user.

Administrators can determine which applications should have access to the specific browser – eliminating use beyond specified programs. End users are never prompted on which browser to use – the correct version automatically opens for them based on policy. This option will help customers move faster and more efficiently to Windows 7 without spending thousands if not millions on upgrading software in the near term.

To learn more, check out Webinformant.tv’s short video on “Running IE v6 on Windows 7 with Symantec Workspace Virtualization.”

* Click on any image to enlarge to full size

(1) In version 6x, from the resource tab or view resources, go to Collections > My Collections and right click to create a new collection.

(2) Edit the collection and choose resource type = computer.

(3) Add the filters that you need.  Note that it will take some time to learn what’s in what table and field in the database.

(4) Select the New Filter button and select the correct table and field to target.

(5) The next example describes how to create a dynamic collection that only includes laptops, excluding desktops.  Using the Inv_AeX_HW_Serial_Number  table and the Computer  Type Field we have selected Laptop, Notebook, and Portable.  We will then join the filters with an “or” statement.

(6) Click Test, then Apply. You are then finished creating a dynamic collection that can be used to deliver software to all laptops that are managed. 

*NOTE: If using this method to move to a new server, make sure that the Server Name and IP Address are the same on both the old and new servers.

Steps:

(1)  Use the Symantec Endpoint Protection “Database Back Up and Restore” utility to take a backup of the SEPM environment including the Log Files. This will do a couple of things:

a. Create a backup of the database which will be stored at C:\Program Files\Symantec\Symantec Endpoint Protection Manager\data\backup\*.zip

b. Create 2 backup files that contain the Private Key for the server.  These files will be labeled “keystore_’date & version of backup here’.jks” and “server_’date & version of backup here’.xml”.  These files will be located at C:\Program Files\Symantec\Symantec Endpoint Protection Manager\Server Private Key Backup\

(2 )  All of these files should be copied to a location that is easily accessible at a later time.

(3)  Uninstall Symantec Endpoint Protection Manager from the Server.

(4)  Restart the server.

(5)  Install the Symantec Endpoint Protection Manager on the desired Drive, using the same installation media version that you just uninstalled from the C: Drive.

(6)  When the Configuration Wizard launches at the end of the Installation, accept most of the standard settings. If your old installation used a SQL DB, make sure that you configure the DB setting to connect to the original database.  This will of course remove your old configuration from the DB, but that’s why we have a back-up.

(7)  Copy the database backup file to <Install Drive>:\Program Files\Symantec\Symantec Endpoint Protection Manager\data\backup\.

(8)  Stop the Service titled “Symantec Endpoint Protection Manager”

(10)  Launch the “Database Back Up and Restore” utility, except this time select “restore” from the main menu; when asked which version to restore, select the one that was just copied to the new SEPM installation path.

(11) Once the restore is complete rename and copy the 2 key backup files to :

“server_’date & version of backup here’.xml” – <Install Drive>:\Program Files\Symantec\ Symantec Endpoint Protection Manager\tomcat\conf\server.xml

“keystore_’date & version of backup here’.jks” – <Install Drive>:\Program Files\Symantec\ Symantec Endpoint Protection Manager\tomcat\etc\keystore.jks

(12)  Run the “Management Server Configuration Wizard” to ‘Reconfigure’ the database, making sure to point it to the same database as was used previously.

(13)  After the reconfiguration is complete, the SEPM Console will launch automatically. You should now be able to log in as you have always done using your security accounts. The Console should indicate that it is communicating and managing the clients that were being managed prior to the SEPM Move.