A few years ago, I was a student in higher education working towards my degree in Computer Science. I almost immediately found that the biggest issue I had was having to go to the university to find a computer to run my tests or to write documentation. I was developing in Turbo Pascal or C or, worse still, access to COBOL (yes, I’m showing my age). It didn’t take long before I was finding the cash to buy myself a home PC.

My chosen weapon was a slimline 386 sx25 with a 40Mb HDD and 2Mb of RAM. This was around $2,000 and rather rapidly required both a larger HDD and RAM (6Mb RAM cost $150). I even bought a 4 color dot matrix printer to add that extra jazz to my assignments.

This PC made a huge difference to my work / life balance as it allowed me to work where I enjoyed – in the comfort of my own home where I had much easier access to conveniences, drinks and food. This has also shaped a lot of my beliefs in terms of knowing that there will always be different ways to perform tasks; it is just a case of thinking a little outside of the usual box.

Around 12 months ago I was working with another higher education establishment to help them with their user strategy. During this work I had a flashback to my own times as a student since the challenge was (in my opinion) very similar.

The college was looking to upgrade their existing VDI solution to the latest and greatest and wanted me to help them understand the actual needs of the students. Initially I was amazed that nobody had engaged with their user base to understand how they interacted with the solutions presented as well as understand how they may prefer to do so. It became super clear that the very same issue was in play – the students and staff did not like having to go in search of a suitable PC. In fact they had already taken matters into their own hands. From my calculations over 85% of the students had their own laptop device (and some had tablets too) that they were using for their assignments. They could use them wherever and whenever they wanted, thus enabling them to be smarter with their own work / life balances. However they were still somewhat stuck in using specific computer rooms to gain access to certain design / CAD applications (this was a fashion and design school) which really infuriated them.

The really silly thing in all of this was that the college was only looking to upgrade the core application set along with the VDI solution, so the specific applications would not be served up via the solution, leaving the self-same issue still hanging around like a bad smell.

Incidentally, this college had recently spent around $500k building a brand new resource in the library with 30 new Mac-based terminals that at 5 months in had only had around 15% usage. Once again the college had not engaged with the students to understand what they needed, and while the Mac was seen as being cool and significantly better than the five 1990’s PC’s that had been there gathering dust previously, the students wanted to use their own laptops to work on, so a big part of that $500k had been somewhat wasted.

The lesson that the college learned pretty quickly was that for any IT projects today, it is highly advantageous to engage with the user population right from the outset and work together to build the right services that will have the most impact.

So, these guys are left considering alternative means to get the relevant applications out to users regardless of the PC that they have on their desk / coffee shop table.

Soon they will be able to use MyWorkNow from 1E to deliver a secured Windows desktop to their student’s devices. The college will also be able to use 1E Shopping to deliver all relevant applications (which will also be reclaimed at the end of the course module). This solution will significantly reduce the overall cost to provision the desktop and applications to users. And the college will have the ability to remove the college desktop (including reclaiming software licenses) from the student devices at the click of a button via AppClarity. The users will have the applications they need where they need them and the college will be able to fully manage them at low cost.

Check out our MyWorkNow LinkedIn Showcase page for more BYOD/BYOPC and MyWorkNow news.

Simon Rust | Director, Product Management

You can follow 1E and wider-industry news and events via Facebook, Google+, LinkedIn, Twitter, and via V1Ewpoint, our monthly newsletter.  To discuss any issues relating to this article with our experts, email info@1e.com, or visit our LinkedIn forum, 1E INSIDEV1EW.

If you found this article helpful, please take a moment to share it with your contacts using the social media buttons to the left. Thank you.

Understand your exposure to unused software and start reclaiming
applications immediately

With over 30% of the software deployed in most organisation being unused or rarely used, with AppClarity you can establish immediate visibility of your exposure, begin reclaiming these applications and make substantial savings in days rather than months or years. AppClarity Reclaim as a Service is a 1E packaged service offering, which will accelerate this process further, providing an immediate view of the unused software within your organization and allow you to begin your software reclaim straight away.

Ahead of a license negotiation, AppClarity Software Reclaim as a Service delivers results in days.

The 1E Approach

AppClarity Reclaim as a service, uses a proven 5-step methodology to ascertain the savings that can be realized and start your software reclaim

Network Ping, DiffServ, QoS or something special?

There are lots of ways to calculate network bandwidth. A network ping can determine WAN speed but this is not ideal as many organizations disable ICMP for many security reasons. Windows firewall alone blocks a lot of ping traffic by default due to the inherent security issues that can be associated by it.
DiffServ can give good Quality of Service (QoS) but requires hardware investment that can utilize this technology not to mention some solutions leveraging this technology only calculates QoS on edge routers. This may be okay for route paths with a short amount of hops (number of routers in-between each edge router) but once we hit the big wide area network we become unable to determine how many hops we take. There’s also the issue of requiring clients to use this technology down at the network level.
This means we need drivers to create these special types of network packets that can utilize DiffServ effectively on each of our clients and Microsoft themselves once attributed that the reason why nearly all windows machines get the dreaded “blue screen of death” was because of drivers.

So how does Nomad do it? Reverse QoS^TM.

Nomad doesn’t want to use QoS. Why? QoS is literally Quality of Service. It ensures that certain packets are prioritised over other packets. What does this mean in laymen terms? It means that your packets compete for bandwidth over a link. This means that the link still can get saturated and that the prioritised packets get “right of way” over these saturated links.
What does Nomad do? Nomad uses a special system called Reverse QoS^TM.

What is Reverse QoS ^TM?

Reverse QoS ^TM is a method that looks at the complete round trip time that it takes blocks of data to traverse a WAN link. It is able to back off or speed up accordingly in a safe manner. This is special because it can actually take everything into account. This includes high CPU utilization of a client down to even disk read latency from the OS. This is hugely beneficial to business due to the fact that network hardware such as router queues do not need to be accounted for as the solution is purely hardware based. It also means that Nomad is able to avoid using any system level drivers that risk a blue screen of death as previously mentioned which could cause havoc to your organization and possibly require the need to visit every system if there is a problem.

So what’s the problem with other methods?

Other methods for network bandwidth throttling soon start to break down when you have multiple network hops and routes through different switches on the way to an endpoint because the only look at edge routers and not the whole end-to-end WAN like Nomad does with Reverse QoS ^TM. You can see how some of the largest organizations in the world like Verizon Wireless, AT&T and Saint-Gobain are actually using Nomad in the video and documented case studies at our Resource Center.

Why run Nomad vs nothing at all?

How does Nomad control your SCCM bandwidth management?
Nomad is a pure software solution which dynamically manages the bandwidth of IT content distribution in order to prioritize business traffic over IT traffic instead of traffic competition where it’s business traffic vs IT traffic. Nomad does this by Reverse QoS™.

By using Nomad in your SCCM (ConfigMgr) designs for branch offices and SCCM bandwidth management you no longer have to deliberate whether one site should be your central location site vs another site. Instead when it comes to Microsoft SCCM WAN bandwidth management at branch offices you can target Applications and Packages without any additional SCCM branch office constraints due to the complete Nomad integration. There is no risk with using Nomad in your SCCM branch office design as it augments the System Center infrastructure rather than compete with it.

Many organizations have a list of key criteria which they want to ask about their environment when evaluating Nomad vs other methods for managing client systems at SCCM branch offices.

How many servers will they reduce to before creating a single point of failure? Nomad reduces the server infrastructure at Microsoft ConfigMgr branch offices more than any other product on the market. It does this without having to ask the question should I deploy this vs will this create a single point of failure because Nomad accounts for all scenarios.

Reducing your network infrastructure VS creating a single point of failure

Nomad also has Binary-level differencing, client cache management and Peer to peer based redundancy and distribution mechanisms of Nomad allow an organization to dramatically reduce infrastructure servers by 95% or more without creating any risk such as a single point of failure or unnecessary client overhead or kernel drivers.
The requirements for many organizations require multiple sites vs one site for many reasons: political, geographical, high availability, disaster recovery reasons, even servicing Internet-facing clients and Nomad can cater for all these scenario where-as others cannot.

Additionally the OSD facilities of Nomad allow organizations to supercharge migration projects without any additional staff and achieve the highest possible amount of automation on most client systems. The PXE Everywhere functionality that is native to the Nomad solution allows for PXE in branch offices to happen without any server infrastructure and still effectively managing the ConfigMgr bandwidth to the branch. Try Nomad for yourself and whittle your list of ten questions down to none and manage the Microsoft SCCM bandwidth for your branch office at one site like you would your central site – in other words manage them all the same.

Troy Martin | Product Manager - Management Infrastructure

Read more about Nomad at http://www.1e.com/nomad/, or follow our LinkedIn Showcase page.

You can follow 1E and wider-industry news and events via Facebook, Google+, LinkedIn, Twitter, and via V1Ewpoint, our monthly newsletter. To discuss any issues relating to this article with our experts, email info@1e.com, or visit our LinkedIn forum, 1E INSIDEV1EW.

If you enjoyed this article, please take a moment to share it with your contacts using the social media buttons to the left. Thank you.

22^nd September, 2014 marks the launch of new versions of two key pieces of technology. One is a new version of our software waste identification and reclaim product, AppClarity. The other is an update to the architectural platform called ActiveEfficiency (AE) that AppClarity and Shopping currently rely on and Nomad, NightWatchman, and the forthcoming MyWorkNow will come to rely on for major future functionality.

Let me start by telling you all a little bit about what Active Efficiency is, and why we at 1E have taken the strategic move to use the architecture and future kingpin in our products. In short, AE is about keeping things standard and enabling a single predicable data layer that all our products can leverage, once we have the data in a predicable format it makes it much easier for our products to consume meaning faster data transfer rates, functionality deliverables and a much richer feature set. Because the data is always presented in the same way by AE rather than the products having to cope with unpredictable formats, each development team just needs to be able to connect to the AE data rather than each product solving connectivity to different data sources in their own way.

So what can you expect from the next release of AppClarity and Active Efficiency? Let me start with AppClarity. If I were to put the release into a particular theme, I would choose “New Platform Support” as from the next release (4.5) there are a number of updated platforms that that AppClarity will be supported on. These include Windows 8.1, Windows Server 2012 R2, SCCM 2012 R2 & SQL 2014, AppClarity can also be put into a migration mode to allow the migration from Configuration Manager 2007 to 2012, and there is also a new look and feel to the product.

With regards to Active Efficiency, we have made it a great deal easier to schedule AppClarity syncs using Active Efficiency, optimized sync performance for both Shopping and AppClarity and added support for soon to be released Nomad functionality.

These features are only the start and as 1E goes down the Active Efficiency road, 1E as a company will benefit in terms of quicker development of features and functionality but more importantly, our customers will benefit from functionality that will allow them to run IT for less. Should you want to know how much we can help, please follow our LinkedIn Showcase page for AppClarity, or contact us at info@1e.com.

Dan O’Connor | Product Manager

You can follow 1E and wider-industry news and events via Facebook, Google+, LinkedIn and Twitter. To discuss any issues relating to this article with our experts, email info@1e.com, or visit our LinkedIn forum, 1E INSIDEV1EW.

If you enjoyed this article, please take a moment to share it with your contacts using the social media buttons to the left. Thank you.

Let me start by asking you a question – would it be easy to imagine Apple without iTunes, or even metaphorically – Amazon.com without Amazon Web Services? 

Let us pause for a moment and think about Amazon. Amazon.com was not initially built to be served out of AWS, but was served out of a more traditional Oracle-backed in-house system. On the other hand, AWS was designed to take the pain away from managing environments, but it made a lot of sense later for Amazon.com to move to AWS. One would ask why, when everything was working so well? Simple really, the goodness around elasticity, efficiency and reliability that AWS brought to Amazon.com was enormous. This not only spurred Amazon.com to greater things, but also got third-parties and developers invested in Amazon to get more out of AWS e.g. the AWS marketplace, and the Amazon AppStore.

That brings me to ActiveEfficiency – 1E’s Efficiency platform.

As regular readers of the 1E blog, we are all familiar with the 1E strategy – to make IT more efficient, be it software, hardware, or the network. Although all our products have a specific narrative and a set of focused goals, there is always an underlying insight these products can feed each other with, e.g. if as a customer of 1E, you’d want to supplement the goodness of one product with another, then ActiveEfficiency is the vehicle that would help you do that. That doesn’t necessarily mean ActiveEfficiency is useful only if you have deployed more than one of 1E’s products. I could summarize ActiveEfficiency as not only being a glue but also a healthy supplement to each of our products.

As a customer of 1E, you could leverage ActiveEfficiency’s core premises in a variety of ways:

 1. Interoperability - ActiveEfficiency Server works well with your existing infrastructure, and can accommodate data from a variety of data sources like Microsoft’s System Center Configuration Manage, through our own agented and agentless discovery mechanisms. What happens if you’ve already bought into a 3rd party data source not on that list? No worries, we can integrate with any data source. By way of an example, we wrote a custom ActiveEfficiency connector for one of the world’s largest financial organizations allowing them to harvest their existing discovery infrastructure without buying into a new discovery mechanism. Consolidation is Efficiency!

2. Enablement and Extensibility - ActiveEfficiency Server is built around RESTful API’s that make it easy to interact with the platform and even extend it. Device Tagging is a perfect example of enabling ActiveEfficiency to accommodate a device attribute unknown to 1E.

3. Collaboration - ActiveEfficiency is built to deliver the best of what we know as quickly as possible down to you. So, that might be enabling our latest software catalogue from the cloud down to your corporate network that ‘AppClarity’ could leverage with immediate effect.

4. Scalability - ActiveEfficiency needs to accommodate large sets of data potentially from different sources, and needs to serve all of 1E’s products. This means there is no question that it has to be performant, and we are constantly striving to improve our performance numbers to further increase efficiency of using 1E products. I will explore this more in a later post so stay tuned.

5. Security - ActiveEfficiency is a secure service, secured using standard Windows Authentication. You can lock down access to the ActiveEfficiency Web Server, to a machine account or a set of user accounts as is appropriate to your environment.

I hope you have found this post useful. In the next post, I’ll dig deeper into the specifics of the recently released version of ActiveEfficiency – ActiveEfficiency 1.7! Stay tuned.

Gokul Raju | Senior Software Engineer

You can follow 1E and wider-industry news and events via Facebook, Google+, LinkedIn and Twitter.

If you found this article helpful, please take a moment to share it with your contacts using the social media buttons to the left.

A recent myITForum community discussion posted on the SCCM email list server raised the question of which technique was the best way to get a bare metal PxE booting computer to find a PxE server that could respond to the PxE boot request. Remember, this is a special case boot option where the computer powers up, essentially using the “F12 – Boot to Network” BIOS option, The system is essentially saying to the  network “Hey!!! Is there anybody out there with a boot image I can use to get up and running here?” In order to “find” the source of such an image (a PxE server that can respond to this request), some assistance from the routed IP network is needed to locate this special purpose server.

In the community discussion IP Helpers were considered the preferred method, as DHCP Options were unpredictable, not working as expected, and caused erroneous error messages during the PxE boot process. Once IP Helpers were employed, things “just worked. This prompted a survey of the community to determine a general consensus on the subject. This produced some very interesting responses, including the fact that DHCP Options are not recommended, and apparently aren’t supported anyway:

http://support.microsoft.com/kb/259670/en-us

TechNet: Important: Microsoft does not support the use of these options on a DHCP server to redirect PXE clients

Using DHCP Options 60, 66, and 67

If you configure these options, client computers will receive an IP address lease, information about the boot server, and information about the NBP directly from the DHCP server. Clients will not contact the Windows Deployment Services server by using DHCP, but they will download the NBP through Trivial File Transfer Protocol (TFTP) on UDP port 4011. Microsoft does not recommend this method for the following reasons:

• Using DHCP options is not as reliable as configuring a router. In testing, clients have incorrectly parsed the DHCP options that were returned from the DHCP server and as a result, the client received a “TFTP Failed” error message. Generally, this problem occurs when the PXE ROM ignores the boot server host name and attempts to download the NBP directly from the DHCP server.
• If there are multiple Windows Deployment Services servers available to service client requests, specifying a specific server may prevent load-balancing. In contrast, using router forwarding tables you can forward the request to multiple servers.
• Clients may be directed to a Windows Deployment Services server that is not available. Because the client does not have to contact a Windows Deployment Services server directly to determine the NBP to download, the DHCP server may direct clients to download a NBP that does not exist or to a server that is not currently available.
• Clients may bypass the Windows Deployment Services server’s answer settings.

Further, one cannot do UEFI or BIOS based PxE booting when using DHCP Options. Regardless, it really doesn’t come down to Microsoft’s support stance, but really comes down to the Network Interface Card (NIC) and what or how the manufacturer implements this process (or not). If the NIC does the wrong thing, it is very difficult to troubleshoot the problem.

Using IP Helpers you can monitor the network traffic to determine where things may be going wrong. It is no longer a function of the NIC. Things just generally “work” better. Furthermore, it is also important to consider BIOS updates as there are often updates to the PxE boot code in them

Then there is this reference that further talks to managing network boot program options:

http://technet.microsoft.com/en-us/library/cc732351(WS.10).aspx

Furthermore, getting all of this to come together properly in some environments you may well find that you will need to meddle with configuring layer 3 switches, or your routers themselves. Add to all of this the simple fact that you need any number of remote PxE servers out in the wild to support this capability in those remote offices and you get a good idea of the cost and hassle related to implementing and managing this capability.

Confused yet?

Well don’t be. There is a better and far simpler! way!

You may already know that 1E Nomad is the proven standard for moving systems management data of all kinds and sizes in an SCCM environment across any size of the wide-area-network with no impact to business traffic. It does this using its patented Reverse-QoS^TM technology. There are a significant number of features and capabilities in this product, but this post will focus on just one.

So what’s Nomad got to do with this OSD and PxE boot scenario and all the IP related fussing about to get it working? Simple, really – Nomad also includes PXE Everywhere (formerly known as PXE Lite)! This is a simple client agent installation that allows the SCCM Administrator to forget about PxE servers and all that cost and confusion entirely. You now have the capability of a traditional PxE server, but delivered via by one or more existing end-user computers on each desired subnet throughout the entire estate. This is accomplished without the need for any IP configuration at all: no IP Helpers; no router configuration; no switch configuration. Simply install the Nomad tools extension on your Configuration Manager server, and configure the Nomad OSD integration components. Then Install the PXE Everywhere Central service and related PXE Everywhere client agents where desired. Now simply plug in the bare metal computer and power it up. The PxE boot request is “seen” by the local PXE Everywhere computer. A quick check by that PXE Everywhere machine to the corresponding PXE Central IIS service for authentication and image determination, and JOB DONE. You now have a PxE boot capability everywhere you need it, and have the added benefit of having the Nomad product to get the content where you need it without impacting the WAN as an added bonus.

The bottom line here is really simple. With 1E Nomad and its PXE Everywhere feature you have a serious OSD and software distribution capability, fully integrated with Configuration Manager with no added infrastructure, no kernel level device drivers, no JAVA dependencies, leveraging industry standard networking protocols, and you’ve eliminated the need for any traditional PxE servers and all the related IP configuration work needed to get it working. All of this is pretty slick technology, and we’ve not even scratched the surface of the native Nomad capabilities at all! That’s a topic that’s already been addressed extensively here on the 1E blog by people far smarter than me. Hopefully this little note will help clear away the fog of IP configuration confusion.

By the way, if you are reading this blog then you really should be on that myITForum list server referenced above! It is a real community-driven gold mine of information for the SCCM Administrator! I hope you found this blog useful. It’s been far too long since my last post, but I intend to be much more active here in the coming months, so stay tuned!

At some point most of us have either rented a car or have considered doing so. Some of us live in rented apartments. Until movies became readily available over the internet, renting them was a common practice. Clearly, in certain instances we see value in renting a commodity instead of buying it. The reason is simple – it’s generally cost-effective to rent something than to buy it outright, especially when you intend to use the commodity for a short interval. 1E’s Shopping, the app store for the enterprise, applies the same real world concept to usage of applications. In Shopping, you can rent an application for a specific interval based on need. All the administrator needs to do is to configure the application as one that is available for Application Rental.

Let’s understand the feature a little more – From an end user’s perspective, all you need to do is make the request for an application, as you would usually do. Since the Shopping administrator has configured the application as one that can be rented, you get the application rental option when you shop for it. In addition to making it very easy for you to rent the application, Shopping also empowers your organization’s administrators to control precisely how applications can be rented. For example, the administrator can control:

1. Rental Period: For how many days can the application be rented
2. Extension Period: Whether any grace period will be provided (if so, for how many days)
3. No. of extensions provided: How many extensions to the application rental period can be provided
4. License Hold Days: Number of days for which the application cannot be re-rented

The benefits are obvious – Since you use the application only for a specific period, the application license is returned back to the central stockpile as soon as your application rental period expires, thus making it available for somebody else to use it. If the application was not rented, the user would have to be proactive in uninstalling the application when the usage declines. How often does that happen realistically? Alternatively, some administrator will have to keep a tab on the Application usage with the idea of pulling the Application back. That too is an administrative overhead. With Shopping’s Application Rental, all this is automated and offered as a self-serve option to the end users.

That’s not all. Shopping Application Rental can also be used for temporary business as usual activities such as providing AD (Active Directory) membership on demand. The AD rental can come in handy when you need AD group memberships to perform certain tasks, ones that you don’t perform frequently, for a short duration. Think of a file-share access, deployment server access etc. In case your organization wants to maintain tight control over the AD group memberships, you can have an administrator drive this function by using the Shop on-behalf of feature. This feature will let the administrator shop on behalf of specific users for this membership. With Application Rental, and many other cost saving features, the intention is to help out Customer run IT for less.

If there is anything you want to share about the Application Rental feature or Shopping (in general), feel free to leave a comment in the space below. To learn more about the software, you can visit either our Shopping microsite, or our LinkedIn Showcase page.

Abhishek Chandhock | Product Manager

You can follow 1E and wider-industry news and events via Facebook, Google+, LinkedIn and Twitter. To discuss any issues relating to this article with our experts, email info@1e.com, visit our LinkedIn forum, 1E INSIDEV1EW.

If you found this article helpful, please take a moment to share it with your contacts using the social media buttons to the left. Thank you.

The NightWatchman management console has been designed to ensure ease of management of the NightWatchman clients and their power behaviour. Its intuitive design enables administrators to quickly define and implement power policies for clients with any level of granularity required.

1E will soon release the 7^th generation of their ‘Best of Breed’ End Point Power Management solution ‘NightWatchman Enterprise’ with an exciting new search tool called the ‘Query UI’.  The query interface allows administrators easy access to underlying power and inventory detail across all NightWatchman clients.

This allows administrators to run some fairly complex SQL queries automatically, using the built in Query options meaning they can find out exactly what is going on with their end points allowing businesses to make informed decisions based on the results that can now be extracted.

For example, within four clicks of the mouse, administrators can now see all the machines that have received a recently applied Power Policy, but more importantly they can identify machines which haven’t, allowing remediation times to be reduced so much quicker.

This can be further enhanced by easily extending its functionality with custom actionable extensions. The extensible interface allows the administrator to quickly and easily interrogate all NightWatchman resources and further streamline operations by allowing the creation and integration of custom command line tools to perform on demand actions on target clients.

For further information on NightWatchman version 7, please visit the NightWatchman Product Page at 1e.com, or request a trial today.

Andy Brand | Solutions Engineer

Check out our new NightWatchman LinkedIn Showcase page to keep up-to-date with product news and insight.

You can follow 1E and wider-industry news and events via Facebook, Google+, LinkedIn and Twitter.

If you found this article helpful, please take a moment to share it with your contacts using the social media buttons to the left. Thank you.

Over the years the folks that operate within End User Computing (EUC) have been on a seemingly endless search for some technology that will revolutionize the way we are able to deliver content to users, reducing cost and improving service as we go.

There have been some significant game changers in the datacenter such as server virtualization which has clearly revolutionized the way the datacenter teams are able to deliver more services at a much lower price point without diminishing the overall quality of service. So what about the EUC space, what have we seen thus far?

Well, Citrix brought us Server Based Computing that made a significant difference to delivering standard desktops to 1,000s of call center (or similar) users who did not require heavyweight applications or significantly differing user experiences from the same service. OK, so there are also some user virtualization solutions that have appeared to help make this latter piece a possibility, but this is also not proving to be game changing.

We saw a start-up from Boston, MA known as Softricity bring their SoftGrid solution to market in the early 2000’s. This solution was to revolutionize the way that we thought about application packaging and delivery since the technology served not only as a packaging tool to compete with the traditional packaging solutions BUT also to enable the enterprise to STREAM the application down to the user Just In Time for the execution. There were some significant isolation challenges to be had with the technology since all applications were isolated from each other and hence had no idea of each other’s existence – clearly a VERY useful feature for certain applications but others, such as the Microsoft Office Suite kind of expect to be able to inter-communicate with each other. In 2006 Microsoft acquired this technology and slowly integrated it into the Microsoft Desktop Optimization Pack (MDOP) battling along with the isolation challenges while on that journey. Today this is one of the defacto means to deliver applications to users given the integration into System Center (that it now enjoys), the fact that it is part of MDOP (and likely a very low cost solution for the enterprise) and the fact that the App-V (as it is now known) solution has become a stable offering that is known to have the best application compatibility of the application virtualization solutions on the market.

A few years later a little start-up called Ardence (had actually been running for 20+ years but still saw itself as a start-up and was also from Boston, MA incidentally, well Waltham just outside Boston) had a great idea – to stream the Operating System down to the user’s PC across the network and boot it in real time. Check out this YouTube video posted way back in 2007 – I recall being in that room in Waltham in mid-2006 watching this demo live and being blown away by the potential for this technology. This kind of follows the principles set out by the Softricity team of delivering the content Just In Time, only this time it was about delivering the ENTIRE PC image, Operating System AND applications from a central point out to the device on the local area network. The demo was a powerful proposition that was very hard to ignore as it promised to close in on a single image to manage and for it to be distributed to the corporate PCs as they booted in the morning (or whenever). Citrix acquired the technology at the end of 2006 to bolster their ability to deliver desktops to users, although it continued to be blighted with a significant problem – hardware compatibility. From recollection that demo lab from the video had around 100 PCs in it and to get it to work, the team needed to guarantee the hardware was identical right down to firmware revisions in order for that demo to give the all-important wow factor. If the hardware was not EXACTLY the same, then more driver software needed to be installed into the image that was streamed to the PCs causing bloat and hence slowing down the whole operation.

What we all saw from the Ardence streaming technology was that streaming the operating system opened an opportunity that we had not seen before – the ability to spin up a brand new operating system at a moment’s notice to be able to interact with it at the speed of now. This effectively meant that IT could act quickly to meet changing requirements of the business, to enable new challenges / opportunities to be met with a powerful business IT solution that was ready to maximise those opportunities. If only there was a way to deal with the hardware compatibility….

Now as we step forward to 2014, if such a solution were to stream an operating system (and associated applications if appropriate) into a hypervisor running on a client’s PC, then it would remove the challenges of hardware compatibility (since the hypervisor has rather handily dealt with this challenge for us) AND would enable the business to realize the meet new challenges at the speed of now. By focusing the IT business on the application set and data access provisioning rather than continuing to battle with driver software (to ensure that each and every new model of PC could be supported) we are able to step forward significantly, supporting many different business needs that we had previously thought of as not possible, such as rapid merger and acquisition transitioning, significantly reducing the cost associated with using contractual workforce and enabling users to operate from home much more effectively using their own existing PC hardware.

MyWorkNow might just be THE solution that helps businesses revolutionize the way that End User Computing delivers content out to the user population. It is coming to a desktop near you very soon, be ready.

Keep up-to-date via our MyWorkNow product pages, and the MyWorkNow LinkedIn Showcase page.

Simon Rust | Director, Product Management

You can follow 1E and wider-industry news and events via Facebook, Google+, LinkedIn, Twitter, and via V1Ewpoint, our monthly newsletter.  To discuss any issues relating to this article with our experts, email info@1e.com, or visit our LinkedIn forum, 1E INSIDEV1EW.

If you found this article helpful, please take a moment to share it with your contacts using the social media buttons to the left. Thank you.

As a follow-up to my previous article about 1E’s efficiency platform, ActiveEfficiency (Enable Efficiency, Leverage ActiveEfficiency!), I am here to talk about our latest update to ActiveEfficiency, the newly released ActiveEfficiency 1.7 !

I intend to explore how ActiveEfficiency Server 1.7 has made significant strides in improving usability, performance, and configurability, thereby delivering better value to the suite of 1E products, such as AppClarity, our Software Asset Management solution, and Shopping, the Enterprise App Store.

Let me take you through all the interesting stuff we’ve been working on for ActiveEfficiency Server 1.7:

‘Migration’ Mode’ for System Center Configuration Manager:

You know that feeling when you are moving house, when everything feels like no-man’s land? What would happen if you embarked on a complex mission to migrate your Systems Management Infrastructure from ConfigManager 2007 to 2012?

• How would you make sure your devices or installations which are in the process of migration are represented consistently?

• How would you make sure you don’t lose any historically collected metrics or information?

• How would you make sure you don’t double-count inventory items, but at the same time make sure inventory is counted at least once?

Hurrah! ActiveEfficiency Server 1.7 now supports running Configuration Manager discovery in Migration mode. This is best suited for organizations running AppClarity wanting to have an up-to date view of their application ecosystem, during migration. A useful aspect of the Migration mode is that it intelligently harvests inventory and usage data from the appropriate SCCM implementation be that 2007 or 2012. It also ensures you do not lose any historically collected information as you migrate forwards into CM2012, thereby making sure your view is not stale and kept up-to-date!

 Lightweight Synchronization for ‘Shopping’ :

1E’s Configuration Manager Discovery mechanism now supports a lightweight mode to  gather inventory required by Shopping. This means two things -

• Synchronizing Microsoft System Center Configuration Manager with ‘Shopping’ is quicker than ever before! We are talking about a 20% increase in synchronization times!

• More importantly, the lightweight  method means Shopping will only download information from ActiveEfficiency that is relevant to Shopping as opposed to a comprehensive data stream, thereby saving precious business bandwidth.

With 1.7, you needn’t use Windows Task Manager to schedule periodically running tasks. The ActiveEfficiency Sync Manager’ is here! Its intuitive interface allows you to setup synchronization schedules for AppClarity and Shopping, replete with configuration options like test mode, which allows one to validate a configured schedule, and user configuration if tasks need to run under the context of non-standard users. Additionally, if you use both AppClarity and Shopping, you can now streamline and chain synchronisation schedules with SCCM, so it is least disruptive to your business, and easily manageable.

AppV 5.0 Support :

ActiveEfficiency Server 1.7 now supports interrogating Microsoft AppV 5.0, which means we can natively harvest Application Virtualization information from Microsoft AppV 5.0. If you have a previously installed version of AppClarity (4.0 onwards), you’ll get the goodness by just upgrading to ActiveEfficiency Server 1.7!

Performance improvement around our core HTTP behavior:

ActiveEfficiency relies on HTTP to service requests from server to client, and we’ve made significant performance improvements to our internal HTTP behavior, leading to a multi-fold increase in client request performance. My colleague talks about it here.

I hope you have as much fun using the latest version of ActiveEfficiency as we’ve had building it! If you have any questions on ActiveEfficiency, or anything else in particular you’d want to hear about, please get in touch with us at info@1e.com.

Gokul Raju | Senior Software Engineer

You can follow 1E and wider-industry news and events via Facebook, Google+, LinkedIn and Twitter.

If you found this article helpful, please take a moment to share it with your contacts using the social media buttons to the left.

In my pre-sales role, when explaining the technical aspect of 1E Nomad, I’m often asked about the impact Nomad has on the end user’s personal computer. Remember, the entire premise is to leverage the existing computers in the estate to facilitate downloading and distribution of Microsoft System Center Configuration Manager (SCCM) content of all kinds. Being concerned about the possible adverse impact this may impart on the users of those machines is a natural concern. Simply saying “trust me, they won’t even know it’s there!” is not an adequate response. This article is intended to convey some real world actual metrics to illustrate the impacts imparted in two different scenarios: a data center server hosting the source content; and, the remote client machine used to download and redistribute that content.

Let’s Review a Bit First

Before we get into the deep end of the technical discussion that follows, let’s take a moment to review what 1E Nomad actually is in the first place, and show a simple illustration of the general concept.

Whenever an enterprise is in the business of managing the deployed estate of personal computers, more often than not they are using SCCM. This very mature solution is the overwhelming market leader in this space. It is a robust, scalable and feature rich tool that manages virtually every aspect of Enterprise level systems management, from hardware and software inventory, desired state compliance, remote control, and arguably the most important of all, software distribution. This software distribution content covers the gamut of routine security patch updates, application software programs, and operating system images of all kinds. As you can imagine, this can mean moving a LOT of content (data) around the enterprise. This doesn’t always go over well with the Network Engineering team responsible for maintaining all those wide area network (WAN) links. One cannot accept a machine on the far end of a WAN link running a 1gb Visio install when the source content is at the headquarters data center, and the user’s machine is half a world away across a number of router hops.

To overcome this problem, standard SCCM design incorporates a system role known as a Distribution Point (DP). This server role is deployed at the remote office and provides a server-server pipeline between the data center and the remote offices. The Administrator uses this role to copy source content from the data center and stage it locally on the DP. This is accomplished in such a fashion that the WAN between the two is not adversely impacted as the content is replicated to the remote DP(s). The user’s machine then installs Visio from that local copy. Sound simple? It is, except for a few key things. Servers and their operating system (OS) are expensive, regardless of whether they are physical or virtual. They need to be maintained and patched like any other server. They hold an instance of IIS, providing yet another potential attack surface for evil doers. They pose additional headaches for the SCCM Administrator managing all the content that needs to be staged, often across hundreds of DPs. Then you have the challenge of managing the hard core road warrior who rarely or never is on a network connection in a traditional office, but lives and dies via remote access methods. Getting even a small and simple set of monthly security patch updates to that person is a totally different challenge. Then there are the OS deployment and imaging challenges, but we won’t even go there for this simple discussion! All of this administrative effort imposes hard and soft dollar costs to the enterprise. Network links can still be overwhelmed if things go wrong, and they do. And on and on… there was a good reason why my telephone was speed-dial #1 in the Network Operations Center when I was an active Administrator!

1E Nomad was designed to make all of these problems go away. It does so by eliminating virtually all of those remote DPs, and instead passes on the chore to existing end user computers in those remote locations at a minimum. Ideally, Nomad is used everywhere! I’ll address that reasoning in a subsequent article. Today, I’ll focus on the basics of how the Nomad agent does its task of downloading and sharing content to the local office, across any kind, speed, and size of WAN links, regardless of the number of router hops, and doing so with no impact to the business traffic that is also traversing the same links. The means by which Nomad is able to accomplish this is using what is known as a Reverse-QoS^TM technique. This allows a single machine on the remote subnet to be dynamically “elected” by its Nomad peers to assume the role of downloading the designated content that the remote machines require, and then sharing that content with its peers. Nomad is initially  invoked by its partner, the SCCM client agent using what is known by SCCM as the “alternate content provider”, 1E Nomad. When SCCM needs content, Nomad is called by SCCM, and the process begins thru to completion. Once all of the content is received by those that require it, the installation proceeds normally. Nomad is done. Of course, the content is retained by all of those Nomad clients in their secure local cache to respond to any future needs for it. Consequently, all  systems management content is only ever transferred once and once only to the remote network.

All of the previous description can be a bit confusing. The following brief animation attempts to illustrate this very basic concept in actual operation, from a data center DP hosting the source content (e.g. that Visio installation media mentioned earlier) across an imaginary WAN of whatever topology to a small branch office of five machines: two laptops, and three desktops. The premise: the SCCM and Nomad client agents are installed; there is an SCCM Visio deployment targeting these machines, and the SCCM client then invokes the alternate content provider Nomad, and the process begins:

I should also add that in the above animation, when the original master comes back on-line (and the Nomad service starts), it sees that it is partially through the download. It then makes a simple content request to its Nomad peers asking if anyone happens to have that Visio package it was in the middle of downloading. At that point, any of the other Nomad peers holding that content will simply respond affirmatively and share the remaining/missing content to complete the process. Likewise, the road warrior, who is essentially a “remote office” of a single machine that happens to be in a hotel room or home office, goes through the exact same process, electing itself as the “master” as there are no peers involved. It proceeds to start downloading the content as long as the connection is present. Once lost, it will simply pick up where it left off upon the next connection to the corporate network. This process continues until all of the content is downloaded.

Now that we have all of that out of the way, lets get back to the original question this article is intended to address: “What’s the hit on the systems running Nomad?”. To answer that, I’ll address first the data center DP serving out content to remote Nomad “master” machines across the enterprise that are actively calling for it. I then illustrate a “worst case” scenario on the downstream client side: the elected master machine that is not only downloading the source content for itself, but is also actively sharing it with its peers on the subnet. The impact on a receiving client is even less so not shown here. Now let’s review each scenario.

Impact on Performance of a Distribution Point

While Nomad typically eliminates the need for 90% or more of existing SCCM Distribution Points (DPs), there will always be a few that remain. Nomad architecture requires the Nomad agent be installed on those DPs servicing Nomad clients.  This allows tight security validation of staged and delivered content (e.g. LSZ hash checking, eliminating any man-in-the-middle attack surface), as well as providing for a Remote Differential Compression (RDC) capability at the binary (not byte) level as and when source content is updated. This allows Nomad to securely deliver content initially, as well as securely delivering only updated data to the clients rather than redistributing an entire package.

The following illustrates the typical performance metrics of a large distribution point server while servicing many Nomad client distribution activities. While this is clearly a high end server with 16 cores, it is clear that the CPU impacts imposed by the Nomad clients in the download process are negligible.

Likewise, the overall disk I/O, measured over a substantial time interval, tells a similar story: overall disk performance is well within all acceptable parameters throughout the monitoring interval. What is also interesting about this particular timeline is that 3/12/2013 also happened to be Patch Tuesday, meaning that routine software update activities are typically unusually high as a result, yet there is no appreciable impact on this system as seen in the following graph.

Impact On A Client Machine in the Master Role

When an SCCM deployment is targeted to a remote group of Nomad equipped machines, as we illustrated earlier one of those machines is dynamically elected as the master machine from among all Nomad clients at the site to assume the responsibility of contacting the remote DP and downloading the required content for them all. This single machine then shares that content with its peers in real time throughout the download process. Consequently, that machine is the “busiest” of all the machines on that subnet in the remote office. This presents the “worst case” utilization scenario as it is not only downloading content across the WAN using the Reverse-QOS ^TM technology, it is also sharing that content with all of the other targeted machines on its subnet.

In this section we monitor CPU utilization, network utilization, and memory on an elected master Nomad device, while it is serving a 500MB file to another Nomad peer on the same subnet. This same machine is also actively running Outlook and streaming internet video at the same time.

In the graphs below, the turquoise box throughout the graphs coincides with the 500MB file being served to a peer from this master.

Overall Observations

1. The CPU utilization was minimally impacted during the transfer

2. Network utilization reached 2% during this test

3. Memory performance also had minimal impact, reaching 15.5% during testing

4. Disk activity is documented in the last graph

CPU Usage by Processor

5. Overall system CPU usage is shown below. The Nomad transfer activity is shown predominantly on CPU 0 in red.

CPU Usage by Process – All Processes

6. All system activity is shown below, but only the Outlook and Internet Explorer processes are significant.

7. Outlook reached approximately 25%, while Internet Explorer was around 10%.

CPU Usage by Process – Nomad/CCMexec Processes Only

8. Only Nomad and CCMexec processes shown for clarity.

9. The highest CPU Usage for the Nomad associated processes on the master devices was CCMexec.exe at 0.25%. This occurred while the 500MB upload test was taking place. Overall CPU consumption was very low.

Client Disk Utilization by Process

10. All system disk activity with noticeable spikes is shown below in red for the system.exe process while transferring the 500MB file to peer.

11. This disk usage did not have a noticeable impact on the device while the video was streaming.

Summary

The laws of physics are clearly in play here, so it would be irresponsible to state that there is zero impact to a client computer; however, it should be clear from the above that the impact of Nomad, whether on a DP servicing a large number of simultaneous remote Nomad master machines, or on a single Nomad client in the act of servicing a download as a master agent is essentially negligible. When I’m asked this question by a prospective customer, I tell them that an end user working on a machine where Nomad is working has virtually no knowledge that this activity is taking place at all. The most an overly observant individual might notice is a busy disk I/O light flashing for no “apparent” reason. Nomad simply “works” from end to end with no effort on the part of the Administrator other than ticking the box enabling Nomad in the SCCM administrative console. The user’s system just “gets” what it needs, when it needs it, while the user continues on about his or her business.

Simplicity itself! I trust this high level of detail and transparency helps as you research and evaluate solutions to aid the challenges facing all SCCM Administrators managing content distribution and related WAN utilization concerns.

Further Reading

This article is tightly focused on only one aspect of the Nomad process. There are far more that will be of interest to the serious researcher. The following links provide additional reading on many aspects of 1E Nomad itself and related topics that also may be of interest.

o http://blogs.1e.com/2014/06/26/why-should-i-use-1e-nomad-when-i-have-a-server-at-each-site/

o http://blogs.1e.com/2014/09/01/nomad-and-binary-differential-replication/

o http://blogs.1e.com/category/1e-products/nomad-2/

o http://blogs.1e.com/2014/07/18/nomad-a-truly-serverless-solution/

o http://blogs.1e.com/2014/06/04/new-branchcache-whitepaper/

o http://www.1e.com/nomad-windows-software-deployment/nomad-technical-faqs/

Read more about Nomad at http://www.1e.com/nomad/, or follow our LinkedIn Showcase page.

Ed Aldrich | Solutions Engineer

You can follow 1E and wider-industry news and events via Facebook, Google+, LinkedIn and Twitter.

If you found this article helpful, please take a moment to share it with your contacts using the social media buttons to the left.

Over the last few weeks I have been building up a series of blog articles that build a picture of the IT landscape and how it is being used today. The premise is pretty simple, our technology users are becoming smarter and more demanding, with new technologies appearing weekly (in some cases daily) to help the user do things in smarter, more efficient ways and their expectations upon IT are greater than they have ever been.

At 1E, we have been building technology solutions for the enterprise for over 10 years to make the technology smarter, more efficient, and above all cost less than it has been and should be doing. Our recent user based technology has been through the Shopping product, that enables the end user to request the applications that they need from a professional enterprise app store, with a full underlying workflow model to automate the request, approval, and subsequent delivery of application software titles to the end user. This software radically reduces the number of moving parts (as well as removing the manual processes) for an enterprise, thus has a profound impact on the cost to deliver application software to end users, while giving them a similar look and feel to how they access applications on their personal devices. MyWorkNow is the latest software offering to be available from 1E to enable the end user to access their corporate desktop in a similarly simply manner, while removing a significant portion of the cost associated with the provisioning of a desktop.

So, it is my pleasure to introduce MyWorkNow as a secure corporate desktop container, streamed from the cloud enabling the enterprise workforce the capability to work from ANY Windows or Mac based PC quickly, easily and securely. MyWorkNow fully integrates into standard corporate identity / authentication systems to ensure that you are always in control of who has entitlement to use a cloud delivered windows desktop, including the capability to revoke access for any given user at any time. MyWorkNow environments may be built using existing Windows desktop OS build toolsets such as MDT, are delivered en-masse to users via the 1E ActiveEfficiency platform making use of (patent pending) FastBoot^TM Operating System Streaming technology. This all ensures the user is quickly operational with their secure corporate desktop; working with their application set and associated data with a minimum of fuss. FastBoot^TM enables a Windows image to be streamed to the user’s PC and booted from DURING the download/ stream process, thus decreasing the time to desktop access for the user.

By working directly with systems management frameworks such as Microsoft System Center infrastructure, MyWorkNow minimizes infrastructure requirements to deliver secure corporate desktops even to users PC’s that are sat outside of the corporate VPN. Corporate data is secured via SSL in transit and encrypted via 256bit AES within the virtual machine on a users’ PC that can optionally be terminated remotely if required.

An enterprise desktop can be delivered to any user on any PC on any network connection rapidly at approximately 10% of the cost of VDI, without any of the drawbacks that VDI brings to the enterprise IT table.

Never before has desktop build and management been so versatile and cost effective.

So there we have it, a complete solution for the provisioning of Windows desktops to users of both Windows and Mac desktop devices, delivering a secured container upon any of the above mentioned PC devices, enabling a user to perform their work duties safe in the knowledge that the corporate Intellectual Property Rights is safe and secure while they continue to use the device of their choice. MyWorkNow will enable a multitude of use cases (beyond the simple Bring Your Own PC) to be more effective and cost less to the business, such as;

• Contractor users
• Outsourcing users
• Bring your own computer users
• Mac in the enterprise
• Mergers and Acquisitions
• Education use case – students own devices
• Application Compatibility

I will blog more about each of these over the coming weeks and months, and you can keep up-to-date via our MyWorkNow product pages, and the MyWorkNow LinkedIn Showcase page. But for now, be ready, MyWorkNow will be coming to a desktop near you soon.

Simon Rust | Director, Product Management

You can follow 1E and wider-industry news and events via Facebook, Google+, LinkedIn, Twitter, and via V1Ewpoint, our monthly newsletter.  To discuss any issues relating to this article with our experts, email info@1e.com, or visit our LinkedIn forum, 1E INSIDEV1EW.

If you found this article helpful, please take a moment to share it with your contacts using the social media buttons to the left. Thank you.

The standard client hardware refresh cycle is an on-going and difficult process adopted by businesses all over the world, and as part of that process, ensuring that the latest power consumption figures exist for every recently purchased PC or Laptop is a lengthy and time consuming process for any end-point management team to maintain.

1E has always maintained a comprehensive database of all the OEM Manufacturer hardware power consumptions, allowing customers to accurately calculate energy usage, CO2 emissions, and savings for their enterprise, no matter what hardware models are deployed amongst their employees. Previously the method for obtaining the power consumption for a new model was done manually by injecting the relevant values into the NightWatchman database using a SQL script generated by 1E Global Support. This would have to be done each time a new hardware model was discovered or added by the business.

NightWatchman Enterprise v7 includes a new intelligent 1E Cloud synchronisation tool which enables the dynamic updating of hardware power consumption data with 1E’s extensive hardware power catalog. Synchronisation with the cloud-based power data catalog ensures any new make and model of machine entering the organization is rapidly and automatically identified and their details are updated to ensure NightWatchman is always reporting as accurately as possible.

For further information on NightWatchman, the global leader in PC Power Management, please visit the NightWatchman Product Page at 1e.com, or request a trial today.

Andy Brand | Solutions Engineer

Check out our new NightWatchman LinkedIn Showcase page to keep up-to-date with product news and insight.

You can follow 1E and wider-industry news and events via Facebook, Google+, LinkedIn, Twitter, and via V1Ewpoint, our monthly newsletter

If you found this article helpful, please take a moment to share it with your contacts using the social media buttons to the left. Thank you.

Operating system deployment (OSD) is extremely successful with Nomad when there is no local Distribution Point. The ConfigMgr OSD content (operating system WIM, drivers, applications, and packages) is copied or pre-cached using Nomad onto computers in the site beforehand. When computers are refreshed or replaced, or new computers are built during a migration or as business as usual the OSD content stored locally on computers in the site can be used instead of the content being pulled across the WAN during OSD.

A popular deployment method is to deliver computers with an OEM image installed to a build centre or depot, install the custom company operating system, and then ship the built computers to remote sites. The aim at the depot is to build large numbers of computers at the same time. Let’s look at the most efficient way of achieving this by starting with the required infrastructure.

The computers will need to be PXE booted into WINPE where the OSD task sequence is started, a PXE infrastructure will be required. We don’t want the OSD content to be pulled across the WAN from a remote Distribution Point, the OSD content will need to be hosted in the depot location.

Option one:

Commission a Windows server to host a ConfigMgr PXE enabled Distribution Point (DP) and distribute the OSD content to the DP. Note that Internet Information Services (IIS) and Windows Deployment Services (WDS) are required.

Option two:

Commission a Windows server with Nomad and PXE Everywhere and pre-cache the OSD content into the Nomad cache. A Windows server operating system (OS) is required to allow Nomad unlimited concurrent connections. Nomad on a desktop OS allows six concurrent connections.

The specification of the Windows server for both options needs to include fast hard disks to ensure that the read requests are processed in a timely fashion. A gigabit network connection would increase the throughput of the data and ensure quick build times. This type of performance can be obtained from an entry level server hardware.

Option two will reduce the management of IIS and WDS, enable the use of a single OSD task sequence for all locations, and deliver continuity to the OSD process. Designing continuity into the build process will ensure the build engineers and support staff are able to troubleshoot OSD issues at any location as all locations use the same build method.

In the second part of this blog series I will discuss OSD task sequence design and Nomad configuration for a depot.

Read more about Nomad at http://www.1e.com/nomad/, or follow our LinkedIn Showcase page.

Peter Clark | Senior Consultant

You can follow 1E and wider-industry news and events via Facebook, Google+, LinkedIn and Twitter.

If you found this article helpful, please take a moment to share it with your contacts using the social media buttons to the left. Thank you.

Background

1E’s industry leading power management solution, NightWatchman, consists of two core elements They are 1E WakeUp (turns systems on using Wake-on-LAN technology); and NightWatchman (turns systems off on a predetermined schedule, while saving open, unsaved, user data in the process). Together they provide the full complement of actions needed for complete power management of the computer estate. This solution may be implemented in an integrated fashion with Microsoft Configuration Manager; or, implemented in a standalone mode independent of any systems management tool. In addition to this on/off management feature, there is a robust reporting engine that provides information suitable for a number of different organizations within the enterprise. These include at a minimum the Facilities Manager (interested in energy consumption and the cost thereof); the Corporate Social Responsibility team (interested in carbon emissions related to energy consumption and green computing); and of course the Administrator (primarily interested in tracking the success and/or failure of wakeups and shutdowns).

Our Support Engineers occasionally get calls from the Administrator asking about how the success/failure reports are derived, i.e. where the data originates, and how it is eventually rendered into the Reporting system. More often than not, this question occurs in the course of troubleshooting a problem where the expected data is not seen in the corresponding reports as expected. This article is highly detailed and intended for this Administrator. It describes how the reports related to the NightWatchman process are derived. I addressed the 1E WakeUp reporting process in a previous article.

Architecture

NightWatchman is a client-server architecture. It consists of a server hosting the NightWatchman Management Center. This server installation consists of a SQL server, an IIS webapp, a web reporting environment, and a management console. The client side consists of the 1E Agent deployed to all managed computers (note: this agent will not install on a server operating system). The console is where the Administrator may arrange client machines into logical groups in a hierarchal fashion, by location, organization, or both. To these groupings are applied policies that govern the desired shutdown behavior and schedules for the hierarchy in whatever way is deemed appropriate for the business. Clients periodically poll this console/server looking for new policy applicable to them (not unlike the ConfigManager polling a Management Point). When new policy exists, the client downloads and applies the new policy (i.e. shutdown behavior and scheduling). As power related events occur on the client, it generates a file in the form of *.afr, and periodically sends these files to the Management Center server in a batch fashion.

On The Client

Within the NightWatchman agent there are a number of messages (individual files in the form of *.afr) that can be created on the client as power related events occur (going into standby; monitor in standby; powered off; powered on; etc). The list of messages that can potentially be generated is quiet large. They may be seen on the server here: C:\Program Files (x86)\1E\NightWatchman Management Center\WebService\Transforms. Every file starting with NWM_ is a possible message from NightWatchman. For the purpose of this document we will only talk about NWM_Shutdown_ and NWM_State_ messages as these are the ones we care about for the purposes of this article.

File Generation

On every power state change the NightWatchman agent generates a new file and stores them locally in C:\Documents and Settings\All Users\Application Data\1E\Reporting\NightWatchman. It does the same for every Shutdown action, including those initiated by the user, and those initiated by NightWatchman. At a minimum the NightWatchman agent must create one message per day if it remains constantly on. That file is generated a midnight (local time) to indicate a 24h period of “always on” time has elapsed.

File Upload Cycle

NightWatchman by default waits until 25 messages have been created before uploading them in a batch fashion. The agent scans its outbox every 10 minutes to see if this minimum number of messages have accumulated. If after 4 hours there are still less than 25 messages, it will upload whatever number have accumulated regardless.

On the NightWatchman Management Center Server

This server, known as the NightWatchman Management Center, consists of two elements: an IIS web service (receives data files from the clients); and a SQL database (fed data from IIS for storage within the database)

On IIS

As discussed above, under IIS there is a webapp running called “AFWebservice” which accepts the files uploaded by the client batch processing described in the File Upload Cycle paragraph. Receipt of these messages is written into the IIS log file called WebService.log, found in C:\ProgramData\1E\NightWatchmanManagementCenter. This IIS app will send the data to its companion SQL server database via Transform files that are found in C:\Program Files (x86)\1E\NightWatchman Management Center\WebService\Transforms. The transforms define how the data is written to SQL. You will also see the name of the SQL Stored Procedure used, and its parameters.

On SQL

The data for the various power state transitions on the clients is written into tbNWM_Load_States. The data relating to shutdown actions is written into tbNWM_Load_Shutdowns. On the SQL server database there is a SQL Agent job (1E NightWatchman, Process load) that processes these pending data insert actions. How often this Job runs depends on your configured environment size selected at install time (i.e. Very Small/Lab; Small; Medium; or Large). Normally it runs approximately once every 50 minutes. This Process Load job will prepare received raw client data relating to power states into the tbNWM_Report_Consumption table. It also prepares the tbNWM_Report_Shutdowns table for the Load Shutdowns data.

Most reports are derived from the tbNWM_Report_Consumption_Daily table data. This table is prepared by the “1E NightWatchman, Process Summaries” Job, which runs approximately once every 4 hours. This SQL Agent job summarizes the data from the tbNWM_Report_Consumption table into tbNWM_Report_Consumption_Daily table for reporting.

Speeding up the Reporting

The best way to speed things up for troubleshooting (only!) so you have reporting data faster is by changing the schedule used by the client’s 1E Agent so that it polls its outbox more frequently, and will send up data with fewer than the default number of messages in the queue.

On the test client(s) edit the registry value: HKEY_LOCAL_MACHINE\SOFTWARE\1E\NightWatchman\Reporting\MinMessagesPerBatch (REG_DWORD) from the default 25 (Dec) to the desired interval. Set this value to a low value (e.g. 3). In this fashion fewer messages are required before the polling cycle will upload them. Likewise, edit the registry key value: HKEY_LOCAL_MACHINE\SOFTWARE\1E\NightWatchman\Reporting\PollIntervalSecs (REG_DWORD) from the default 600 (Dec, or 10 minutes) to the desired interval (e.g. 300, or 5 minutes). While the client agent’s periodic polling for new policy (and related settings, including these) should return the above settings back to the default values on the next poll interval, DO NOT FORGET TO DELETE THIS KEY WHEN FINISHED TROUBLESHOOTING!

Summary

This article explains the basics of how NightWatchman reporting data is generated; how and how often the process is initiated; how power state transitions and shutdown activity success and failure data is generated; how that data is fed to the NightWatchman Management Center server; how its IIS and SQL server components interact to load the database; and how to speed up that process for troubleshooting and subsequent reporting. I also address the companion 1E WakeUp process as it relates to the success and failure of wakeup activities in a separate, companion, blog.

Acknowledgement

The core data used in this article was developed by my colleague and former Lead Support Engineer, Reto Egeter.

Read more about NightWatchman at http://www.1e.com/nightwatchman/, or follow our LinkedIn Showcase page.

Ed Aldrich | Solutions Engineer

You can follow 1E and wider-industry news and events via Facebook, Google+, LinkedIn and Twitter, or by signing up to our monthly content newsletter, V1Ewpoint.

If you found this article helpful, please take a moment to share it with your contacts using the social media buttons to the left.

USGCB stands for “United States Government Compliance Baseline”. The USGCB is a Federal government-wide initiative that provides guidance to agencies on what should be done to improve and maintain an effective configuration settings focusing primarily on security. The USGCB baseline evolved from the Federal Desktop Core Configuration mandate, to create security configuration baselines for Information Technology products widely deployed across the federal agencies.

The federal agencies are only allowed to deploy and implement software solutions which are USGCB compliant. Therefore organizations trying to sell their software solutions to federal agencies must ensure that their solution has been tested and verified on USGCB Compliant environment.

So how can an organization ensure that their product is ready for federal agency environment?

The environment must be prepared to the agreed standards and settings, and then validated using an approved compliance scanning tool: for example- CIS-CAT, which run set of pre-defined tests and provides a report indicating USGCB compliance level of said environment.

CIS-CAT stands for Center for Internet Security-Configuration Assessment Tool. CIS-CAT is a Security Content Automation Protocol (SCAP) tool, approved by NIST (National Institute of Standards and Technology).  This tool can be run independently on a target machine or against group of target machines to determine the compliance level of the target environment.

At 1E we have outlined a high level approach to prove the USGCB compliance for 1E products should the need arise. The approach involves following steps:

• Run the approved compliance scanning tool on the USGCB compliant environment and ensure that the reported scanning results are 100%.
• Install the product under test, on USGCB compliant environment.
• Re-run approved compliance scanning tool to confirm, that none of the pre-defined security settings has been altered/manipulated by the installed software.
• Perform the product testing.
• Before the testing is officially closed on specific environment, re-run the approved compliance tool to prove that USGCB compliance is still valid and 100%.
• The test reports/artefacts’ generated at every stage must be stored for audit purposes.

This would prove that the tested 1E product works as expected in the compliant environment and none of the USGCB recommended security settings were altered/manipulated during the process of installation or testing.

This approach is simple, but the execution may be far more complex.   Getting a product to work as expected in a USGCB environment may need special configurations (and possible limitations) to be identified and documented, and may even result in subsequent product changes being required, which of course would complicate things.

Mamta Singh | Senior QA Analyst

You can follow 1E and wider-industry news and events via Facebook, Google+, LinkedIn and Twitter, or by signing up to our monthly content newsletter, V1Ewpoint.

If you found this article helpful, please take a moment to share it with your contacts using the social media buttons to the left.

It is my pleasure to announce that the 5.1 version of Shopping, our Enterprise AppStore, is now available. The Shopping 5.0 version was a game-changer in the way it provided a consumer grade experience to users when they try to obtain desktop Apps, web Apps, virtualized Apps, file share privileges, AD group membership requests,  hardware requests, and other IT service requests. This is something a typical consumer of IT service requests never had before. Shopping 5.1 takes an evolutionary approach in taking the game forward and provides a host of technological and usability upgrades to the already industry best solution.

If I were to divide the 5.1 release into themes, I will say there are three central themes to it – Security, Usability and Technical advancements.

Security - Shopping is now fully compliant with the Role Based Access Control in SCCM 2012. But how does it make Shopping more secure? To understand this, let’s first understand what Role based access control means to Config Manager 2012. RBAC provides Configuration Manager administrators an easy way to implement the security model that allows them to assign and manage administrative permissions by assigning which actions they are able to perform using security roles, which users and systems they can manage through collections, and which objects they can access using security scopes. As a solution that uses Config manager as its vehicle of delivery to install software on the applicant user’s machine, Shopping’s compatibility with the security protocol implemented by SCCM 12 is a natural fit. By adhering to the these rules, Shopping ensures that the SCCM Admins can continue to use RBAC based security rules to control access for a single and flexible model across the enterprise. In simpler words, by reducing one potentially moving part from your underlying SCCM implementation that Shopping leverages, Shopping enables your Org to finally move towards a “Single Pane of Glass” for software and service interactions between IT and the end user.

To get a sneak peek into the Shopping RBAC compatibility, please have a look at our quick video – Shopping 5.1 RBAC Compliance video

Another security enforcement is the new splash/welcome message, which comes in handy when you want to centrally enforce your corporate policies or make the user accept the terms and conditions, before the user can start using Shopping.

Usability – The full App Store experience can also now be had on the touch devices. Shopping 5.1, when run in its recommended resolution, is compatible with iPad, Surface Pro, and touch monitors running Windows.

Technical Advancements – Shopping has also made subtle, but significant changes to its search functionality. Search is at the heart of any consumer grade software solution. As the number of Apps in your enterprise App Store proliferate, finding those Apps quickly and accurately becomes even more important. Most of the advancements to the search functionality are under the skin. Shopping now uses industry leading search engine platform to provide faster, more accurate search results displayed in order of relevance, with keywords clearly highlighted. It’s really quick – For most search queries, you can expect a sub second response.

We also made your transition to a new Shopping version smoother – Two Shopping systems can now be run in parallel with the same SCCM and Active Directory installation. This helps you to setup a new Shopping version without disturbing existing Customer configuration. Given this new capability, new releases of the Shopping technology may be run in pilot alongside existing systems before migrating the users to the newer release and finally deprecating the previous version, all without the user population having any knowledge of the transition.

This is just the tip of the iceberg – We have myriad of other additions that make the Shopping 5.1 a must try product.

To learn more about the new features, please have a look at – Shopping 5.1 feature video

To learn more about Shopping, the enterprise app store from 1E, visit the Shopping Product Page at our website.

Abhishek Chandhock | Product Owner

You can follow 1E and wider-industry news and events via Facebook, Google+, LinkedIn and Twitter, or by signing up to our monthly content newsletter, V1Ewpoint.

If you found this article helpful, please take a moment to share it with your contacts using the social media buttons to the left.

Introduction

Hello Everyone,

Over the last 18 months, we’ve introduced several exciting features in Nomad focused on extending content availability, accelerating Windows migrations and protecting user-data during the same:

• What’s New in Nomad 2012 V5.2
• 1E Nomad 2012 V5 Has Been Released! Get It Now

What’s New in Nomad 5.5

Today we continue that legacy, introducing two more game-changing features in this release of Nomad 5.5 and PXE Everywhere 2.3!!

• Integration with the WakeUp component of NightWatchman
• UEFI Support (Unified Extensible Firmware Interface) in PXE Everywhere

Integration with the WakeUp component of NightWatchman

Enables machines with content that are currently shut down or in a low power-state, to be woken up when a Nomad peer requires content. This includes both machines that are on the local subnet, or a remote subnet at the same site/location via Active Efficiency® Single Site Download (SSD) feature.

WakeUp integration is not only available to Nomad running in a full operating system, but also when running under Windows PE during a Windows migration. WakeUp integration is particularly useful in this case because Windows operating system images (.wim files) tend to be large. Below is a screenshot of a Nomad task sequence action where WakeUp integration has been enabled.

With Nomad and WakeUp integration, we saw the opportunity to improve upon the NightWatchman energy savings. This feature allows computers to remain powered off even longer, until they are absolutely needed to provide content to peer machines.

Feature Dependencies

The feature has the following dependencies:

• ActiveEfficiency 1.8 or greater
• 1E Agent 7.0 or greater (e.g. WakeUp component only)
• NightWatchman Management Center 7.0 or greater
• WakeUp Server 7.0 or greater

UEFI Support (Unified Extensible Firmware Interface) in PXE Everywhere

Today’s modern hardware are rapidly deprecating the use of traditional or legacy BIOS, but adopting UEFI as their new standard. For example, most newer Windows Tablet PCs only support UEFI boot and not legacy BIOS.

Bundled with Nomad, PXE Everywhere’s UEFI support enables customers to do bare metal deployments of Windows 7 or 8 and later standard corporate images, to any modern hardware device, in exactly the same way.

Nomad Upgrade Guide

Whether upgrading from a previous version of Nomad and PXE Everywhere, or deploying them for the first time, we have helped to simplify the process in a Nomad Upgrade Guide. If you’re not ready to read the entire white paper, then have a quick read of the blog series which provides an overview of various topics covered by the white paper:

• Are Nomad Upgrades Always Easy
• Key Considerations
• Planning the Upgrade
• Best Practices

Finally, Paul Thomsen and I put together a webinar about the white paper you may find helpful as well.

More information

To learn more about Nomad, read other blogs written by the Nomad Product Team, Engineering and Professional Services.

Product Life Cycle & Support Statement for previous versions

Along with this release of Nomad 5.5, Nomad 5.2 is the only other version still in support. Nomad 5.2 support end-date is December 2015. All other versions are currently out of support. Be sure to check the SupportPortal for the Support Life Cycle status of all 1E products.

Nomad and WakeUp integration, and UEFI support have been long-awaited features. We at 1E are proud to be delivering these two game-changing features in this latest release of Nomad.

Thanks,

Troy Martin | Product Manager – Management Infrastructure

You can follow 1E and wider-industry news and events via Facebook, Google+, LinkedIn and Twitter, or by signing up to our monthly content newsletter, V1Ewpoint.

If you found this article helpful, please take a moment to share it with your contacts using the social media buttons to the left.

Occasionally in my series of articles I want to address some tips around troubleshooting various issues that may crop up related to our product line. In this first of that type of post, I’ll address a recent example I saw internally with an engineer doing some work in a lab environment. I thought this might be interesting for our 1E Shopping customers should you uncover a similar scenario. This article assumes a complete understanding of the Shopping product, its architecture and component parts, as well as our integration with ConfigManager

A colleague recently ran into an unusual issue on a test machine in a Hyper-V lab using 1E Shopping and its integration with Configuration Manager 2012 software distribution. As you likely know, when a title is shopped for (an order is placed) Shopping automates the creation and execution of the ConfigManager components to deploy the requested software once approved, if required; or, it is deployed immediately otherwise.

The Problem

When deploying the software manually using SCCM it works perfectly fine (manually creating the package, then the target collection and then the deployment). When doing exactly the same thing with the same package via Shopping it fails with following error:

An error occurred while preparing to run the program for deployment “PRI20014″ (“PRI00007″ – “Per-user attended”). Additional program proper
ties:

Command line: msiexec.exe ALLUSERS=”” /m MSIYRQRH /i “Winzip.msi”

Working directory:

Drive letter (? = any):

 Possible cause: This message most commonly occurs when the program’s command-line executable file could not be found or when a required drive letter connection to a distribution point could not be established.

Solution: Check each of the items listed above

The description of the deployment error is shown as “Failed (Bad environment)” in the SCCM deployments section under the Monitoring tab. The collection and deployment is created normally via the Shopping integration process, but for some reason the MSI installer package (which ultimately has to run on the client machine) doesn’t get copied to  the local CCMCache location on the client machine from the distribution point.  The SCCM primary machine in this lab environment is also the distribution point. I’ve tried multiple options that are available as a probable solution on the internet but to no help. I even created a fresh client machine from scratch to get rid of any old environment related issue but it failed again with same error.

The Environment

This lab environment consisted of a SCCM 2012 SP1 environment with a CAS and a single primary running on separate Server 2012 standard editionx64 servers. Boundaries were configured as 10.10.26.28-10.10.26.61, where the Win7SP1 client was 10.10.26.30. Of course, since this is a Hyper-V lab, the DISTRIBUTION POINT component in the package properties were set automatically assuming a fast network. Below are the properties of the deployment (in SCCM) which was created by Shopping. Here you can see the option for high speed LAN environment and for slow and unreliable network boundary conditions.

Note above that the DP property says “Do not run program” if the client is detected on a slow network.

The Resolution

In this Hyper-V lab the client computer policy refresh (which initiates SCCM deployments) was treating the local network condition as “Slow and unreliable”. As a result, the option set for such a network condition (“Do not run program”, shown above) was coming into play. The policy refresh was therefore not taking any action and the deployment failed every time. This failure was consistent for other client computers as well that were present in the Hyper-V lab. In fact a new VM was created from scratch to eliminate any possibility of a machine specific issue. There was clearly something to do with the lab environment itself. It was unclear if the issue resulted from Hyper-V, SCCM, operating system, networking or something else entirely. When the remote client flags value was changed from 0 (which was being used as the default in this lab) to 3152, both of the deployment options were then set to “Download content from distribution point and run locally”. With this setting, even when the SCCM client evaluated the network as slow and unreliable, it downloaded the content and ran it locally resulting in a successful deployment.

While the package/program itself did not change between the “manual“ deployment test (via native ConfigManager) and using Shopping to do the same thing, the ConfigMgr program deployment itself has.

The Shopping Receiver creates the program’s deployment based upon the values specified by “AdvertFlags” and “RemoteClientFlags”.  These values and their meaning are documented here. If you compare the “successful” (manual) deployment object to that created by the Shopping Receiver, you may find an important difference, and one that can be corrected by adjusting the value of one of these two settings in the Shopping.Receiver.exe.config file.

The issue: the default value for the Receiver’s RemoteClientFlags is 2096, which includes bit 5 (interpreted by SCCM as “Do not run the program if there is no local distribution point”). This also happens to be the default value used by native SCCM for deployments created via the console.  A typical setting for using Shopping in a lab is to set the RemoteClientFlags setting to 3152, as noted earlier (Bits 4,6,10,11), with Bit 6 enabling “Download the program from the remote distribution point and run locally” for both network options above.

With further investigation, it was also determined that SCCM somehow evaluated the client as being on a “slow and unreliable network” in this Hyper-V environment! Consequently the package would not download at all, returning the error message text as shown above.

Further contributing to this was the fact that the Deployment was set to “run from Distribution Point”, but the package didn’t have the legacy share option enabled (you can’t run a program from a DP unless it has the legacy share option enabled.  The package cannot have a working directory of HTTP://).

In Summary

• If you have defined any remote boundaries or want your clients to use a fallback distribution point, you’ll need to change the  RemoteClientFlags setting if you want these clients to install software
• You can specify the REMOTECLIENTFLAGS property when you install the Shopping, or edit the Shopping.Receiver.exe.config file to modify the setting post-installation.
• Task sequences also have their own Remote client flag. Add bit 9 to allow your clients to download task sequence content from a remote distribution point.

Acknowledgements

Thanks to Rasik Bihari for raising and documenting this issue; and, to Duane Gardiner of our Professional Services team for the diagnostics and troubleshooting efforts that identified the root cause, its resolution, and assistance drafting this article.

Ed Aldrich | Solutions Engineer

You can follow 1E and wider-industry news and events via Facebook, Google+, LinkedIn and Twitter, or by signing up to our monthly content newsletter, V1Ewpoint.

If you found this article helpful, please take a moment to share it with your contacts using the social media buttons to the left.

Background

This article concentrates on one little-known aspect of the wake-on-LAN portion of 1E NightWatchman. This product is capable of being installed in a so-called “integrated” fashion, where it becomes part of the System Center Configuration Manager (SCCM) product; and, in a “stand-alone” model where it is integral to the NightWatchman Management Center (NWMMC; i.e. no dependency on existence of SCCM). In both scenarios, a fundamental element of its wakeup operation is to ensure there is a proxy 1E Agent up and running at all times on every subnet. This agent then assumes a proxy function working in concert with the server-side agent to receive wakeup requests from the server and to then create and issue magic packets to its subnet neighbors. Part of this process is the method whereby the WakeUp Server component finds a partner agent on each subnet, and a second backup agent to support this process. These agents are known as the Primary and Alternate agents on each subnet. The end goal is to find a pair of machines where these roles may be assigned. We will also ensure one or the other of these agents is up and running at all times to process those wakeup requests. That latter process, known as “Last Man Standing”, will be discussed in a subsequent article. This article provides a high level overview of the discovery and assignment process to identify and assign the two roles initially.

Agent Discovery Overview                         

Before we dive into the deep end, let’s take a moment to review the high level process before we go under the hood with specifics. This comes directly from the product documentation. Once installed, the WakeUp Server component scans the subnets associated with its site. More on that later when we discuss the AgentList.dat file. This purpose is to find a pair of agents to register as the site’s Primary and Alternate proxy agents to be called upon for subsequent wakeups on each subnet.

Within the WakeUp Server console, the Agent Finder screen, below, controls how 1E Agents are discovered (using ping packets) when using Multi-Agent mode. The WakeUp Server process is identical regardless of using SCCM integrated or standalone mode. In our discussion we assume the default installation scenario known as “Multi-Agent” mode. This implies a 1E Agent is installed on every computer in the estate. You can set the number and frequency of pings sent, the timeout for receiving a response and how often the subnet is rescanned. This lets you set a balance between successfully finding all the Agents against the amount of network traffic generated.

The ultimate result of all this is seen in the Agents node of the console, below. This screen displays a list of all discovered 1E Agent systems, by subnet, and enables centralized control over their settings. When a subnet is discovered, and a pair of agents found, the Primary and Alternate Agents are displayed under Agent List.

Discovery Stage 1

The following picture shows the WakeUp Server scanning the target subnets for a running 1E Agent. By default the scan is biased towards any servers or workstations on the subnet and lowest in the priority are laptop PCs.

Discovery Stage 2

The 1E Agents on the remote subnet respond to the WakeUp Server scan by declaring themselves up and running and available to distribute any wakeup calls, as shown in the following picture

Discovery Stage 3

The first two 1E Agents to respond are stored by the WakeUp Server on the SCCM Primary Site Server (integrated mode) or the NightWatchman Management Center server (stand-alone mode). The first Agent is stored as the Primary Agent; the second becomes the Alternate Agent.

Agent Discovery Detail

Now that we’ve established the basic groundwork around the general concepts and process flows used to find and register these agents on each subnet, let’s go into the details of just how this is actually happening under the hood. Assume the processes are the same in integrated and stand-alone scenarios unless otherwise stated.

1. The WakeUp Server service starts
2. Its AgentFinder thread initiates
3. AgentFinder evaluates its companion data file AgentList.dat for the list of known subnets
   1. See more on this file and its purpose under Agent State Manager later in this article
4. It also evaluates the NWMMC or SCCM db for all subnets reported by the WakeUp clients
5. Known subnets are listed in the WakeUp Console
6. Subnets are processed using PING to look for awake agents
7. responding agents are evaluated for assignment criteria (suitability as primary or alternate agent role)
8. the first two are registered as Primary and Alternate agents
   1. Confirm that the registered clients have the following in the WakeUp Registry:

HKEY_LOCAL_MACHINE\SOFTWARE\1E\WakeUpAgt\

Value Name:   MiniAgentTo

Value Data:      ‘Insert name of WakeUp Server’

What determines which machine becomes a primary or an alternate?

• The first machine to respond to an agent discovery request by the WakeUp server becomes the primary and the second becomes the alternate.
• If there is just one agent discovered on the subnet i.e. the primary, the first machine it wakes up as part of a wakeup job is forced to become the alternate.
• An agent which was previously a primary or alternate comes up, it assumes the role of an alternate and then probes the subnet for an existing primary. If no primary agent exists, it automatically becomes the primary and registers itself with the WakeUp server as the primary. If a primary already exists, then it registers as an alternate, which forces the WakeUp server to unregister a previously registered alternate agent (should one exist). Please note that this exchange of messaging (again UDP) happens when a machine comes up, so there could be timing issues here.

To manually force the AgentFinder process

1. 1. Stop the WakeUp Server service
2. Delete the AgentList.dat file from its default location here:

C:\Documents and Settings\All Users\Application Data\1E\WakeUpSvr\AgentList.dat

3. Set the following registry value to ON:

HKLM\Software\1E\WakeUpSvr\AgentManager=ON

4. Start the WakeUp server service
5. After the WakeUp server service has started wait for a few minutes and the Agent Manager thread will start.
6. You should see something similar in the WakeUp Server agent log:

17/06/2009 13:05:08: WakeUpSvr Copyright (c) 1999-2009 1E Ltd. (5.6.10.3r50796) – Service Started

Software\1E\WakeUpSvr\Strategy=”AFRStrategy”

Software\1E\WakeUpSvr\AgentManager=”ON”

17/06/2009 13:05:08: new file C:\Documents and Settings\All Users\Application Data\1E\WakeUpSvr\AgentList.dat

17/06/2009 13:05:18: Agentfinder started

17/06/2009 13:06:08: AgentManager: Processing subnet ‘192.168.0.0\255.255.255.0′

17/06/2009 13:06:08: Creating an entry for 192.168.0.0 [255.255.255.0]

17/06/2009 13:06:08: AgentManager: Processing subnet ‘192.168.1.0\255.255.255.0′

17/06/2009 13:06:08: Creating an entry for 192.168.1.0 [255.255.255.0]

17/06/2009 13:06:16: AgentFinder Rescan 192.168.10.0 Requested

17/06/2009 13:06:16: Finding agent(s) subnet – 192.168.10.0 [255.255.255.0]

New Agent found 192.168.10.10 for subnet 192.168.10.0

17/06/2009 13:06:19: AGTSTAT4 from XP2 for subnet 192.168.10.0Note: (Note: where XP2 is the NetBIOS machine name found)

Agent ‘XP2, 0, 0, mask=255.255.255.0′ registering for subnet ‘192.168.10.0’

17/06/2009 13:06:19: subnet-192.168.10.0 – Agents=1 OK_pings=2

More on the Agent State Manager

Now that we’ve been swimming about in the deep end of the pool for a while, and the general concepts and related processes have been documented at length, it’s time to add a bit more along the lines of “current Events” related to the Agent State Manager (formerly known in earlier versions as the AgentFinder) process as it is today. There’s a bit of a difference between the way that the Agent State Manager works in SCCM mode vs Stand-alone (formerly referred to as the AFR mode– for the legacy name of the Agility Framework Reporting database use by the NightWatchman management Center).

The Agent State Manager today

• It is a background task in WakeUp Server which runs by default every 10 minutes
• It can be enabled/disabled by setting the “AgentStateManager” registry key (remember, it used to be called just “AgentManager” in 5.6 and previous versions)
• Its job is to ensure that, for all the subnets that are registered in the AgentList.dat file, there are contactable agents which do the job of waking up peers

However, before this process kicks in, one of the first things WakeUp Server does is to work out its boundaries.

• In AFR mode/strategy, it makes a call to the AFR Web Service: “I’m WakeUp Server X – what are the subnet/IP range boundaries which have been defined for me in the NWMC Console?”
• In SCCM strategy, it queries the local SCCM server and retrieves the boundaries for that site
• It then makes the same call to the AFR Web Service
• It then merges the results (i.e. SCCM boundaries merged with the NWMC Console-defined boundaries)

Now WakeUp Server has its boundaries and, if enabled, the Agent State Manager can do its thing. Remember, the IP boundary information controls which subnets and machines it is solely responsible for. This is why we require WU Server to be installed on all SCCM Primaries in SCCM mode, as well as all NWMMC servers should there be more than one in the estate. Now, Every 10 minutes, the Agent State Manager will first try and “discover” new subnets – but it only does this in the AFR (Stand-alone) strategy.

• It makes another call to the AFR Web Service and gets the distinct list of subnets for all the network adapters stored in the database
• It then goes through this list, and discards anything which falls outside of its configured boundaries
• It adds the subnets which ARE inside of its boundaries into the AgentList.dat file, if they aren’t already there
• Any subnets which weren’t in the AgentList.dat file beforehand are considered “new”.

Next, it will delete subnets which have been unreachable for more than a set amount of time (default 30 days), and will also mark as “stale” (i.e. needing rediscovery) those subnets from which we have had no communication in a set amount of time (default 3 hours).

Now we’ve got subnets marked as “new”, and others marked as “stale”. These are the subnets that need discovery.

WakeUp Server will then process the first ten of these (adjustable using the “MaxSubnetsPerPoll” setting), and will queue them for Agent Discovery, as described in detail earlier. If there are more than ten to process, the remainder (the next ten) will get dealt with the next time round (i.e. after 10 minutes). This process continues until all subnets are processed.

The process described above in the “To manually force the AgentFinder process” section will only work in AFR strategy, and will only actually find Agents at a rate of ten subnets every ten minutes. In the SCCM strategy, the subnets are discovered on-demand, so they will only appear in the WakeUp Server console (which is a reflection of the AgentList.dat file) once an initial wake up request has been sent to them. This last statement is often a cause of confusion for the new Administrator, as the expectations is “OK, I’ve got all this installed, but it’s now a day later and I only see a few of my subnets! Where are all the rest?”. Simple: there has yet to be a deployment targeted at them! Be patient. They will appear just fine.

That said, you may ask why does the Agent State Manager only proactively discover new subnets in the AFR strategy. It’s a historic thing. Back in the day when our AFR strategy supported only one WakeUp Server (prior to v6.0.500), it was easy for an AFR WakeUp Server to determine which subnets it cared about – it cared about all the subnets for all the adapters in the AFR database. This wasn’t so easy to do in the SCCM strategy however, because SCCM might have been configured to use boundaries based on IP ranges as well as subnets. So, for example, if SCCM site A looks after, 192.168.0.1 – 192.168.0.128, and SCCM site B looks after 192.168.0.129 – 192.168.0.255, neither WakeUp Server for Site A nor WakeUp Server for Site B really owns the 192.168.0.0 subnet. This was the reason for the “lazy” discovery of subnets – the first WakeUp Server asked to do a wake up on that subnet would try and do the discovery.

This logic is less applicable today, as now you can also have multiple WakeUp Severs in the AFR strategy, and these can be configured to use IP address ranges too. The problem of ownership of a “shared” subnet (as in the example above) still exists, which is why generally you should avoid splitting an individual subnet between multiple WakeUp Servers wherever possible.

The differences between installing WakeUp Server in the AFR and SCCM strategies are becoming less with each release. Since v6.0.500 and the notion of configuring your boundaries in NightWatchman Management Center, WakeUp Server requires the whole AFR backend (in order to pull down boundary information) irrespective of the strategy. It would make sense that, as these differences gradually disappear, we do away with the whole concept of strategy and simplify things by having WakeUp Server “just work”. For that eventuality, “stay tuned”!

Hopefully this series of articles shed adequate light on how the process of discovering subnets, and finding a pair of proxy agents to work with, now makes much more sense, regardless of how you have NightWatchman installed and configured.

(Special thanks to James Davies and Andy Brand for their valuable assistance in this article)

Ed Aldrich | Solutions Engineer

You can follow 1E and wider-industry news and events via Facebook, Google+, LinkedIn and Twitter, or by signing up to our monthly content newsletter, V1Ewpoint.

If you found this article helpful, please take a moment to share it with your contacts using the social media buttons to the left.